Я работаю над проектом, в котором я пытаюсь решить, использовать ли стандартную реляционную базу данных SQL или объекты JSON для хранения данных о событии или деятельности.
Проект будет хранить данные о нескольких типах событий, поэтому я решил просто описать один тип событий для этого вопроса.
Событие с живой музыкой (полностью описанное с использованием схемы JSON внизу этого вопроса) - это объект, в котором хранятся такие данные, как место, где будет происходить событие, время / дата события и стоимость события. Объект события живой музыки имеет как один-к-одному (событие -> имя, событие -> описание), так и один-ко-многим (событие -> места проведения, событие -> даты, событие -> типы билетов ) отношения. Кроме того, объект события может содержать один или несколько идентификаторов исполнителя, которые ссылаются на объект исполнителя. Объект исполнителя хранит данные о музыкантах, которые выступают на концерте живой музыки.
Данные будут запрашиваться пользователями, использующими как простые («Найти меня события с« x »имя»), так и сложные («Найти меня события с музыкальным жанром« x »и стоимостью у» в радиусе «z» от моего текущего местоположение ") запросов. Данные будут предоставлены пользователями с помощью веб-формы.
Как вы, вероятно, можете сказать из определенной схемы JSON, я первоначально собирался использовать объекты JSON для хранения этих данных, но я слышал от некоторых людей, которые говорят, что, поскольку мои данные являются чисто реляционными, я должен придерживаться более старых методов.
Буду признателен за любые мысли о плюсах и минусах каждого подхода с учетом моих потребностей. Если вам нужно что-то разъяснить, пожалуйста, не стесняйтесь спрашивать.
{
"event": {
"eventID":{
"type":"string"
},
"eventType":{
"type":"array",
"eventTypeItem":{
"type":"string"
}
},
"eventName":{
"type":"string"
},
"eventDescription":{
"type":"string"
},
"eventVenueList":{
"type":"array",
"eventVenueListID":{
"type":"integer"
}
},
"eventURL":{
"type":"string"
},
"eventTwitter":{
"type":"string"
},
"eventFB":{
"type":"string"
},
"eventInstagram":{
"type":"string"
},
"eventEmail":{
"type":"string",
"format":"email"
},
"eventContactPerson":{
"type":"string"
},
"eventDoorTime": {
"type":"string",
"format":"date-time"
},
"eventPerformerIDList":{
"type":"array",
"liveMusicPerformerID":{
"type":"integer"
}
},
"eventSetList":{
"type":"array",
"eventPerformerID":{
"type":"integer"
},
"eventPerformerStartTime":{
"type":"string",
"format":"date-time"
},
"eventPerformerEndTime":{
"type":"string",
"format":"date-time"
}
},
"eventDateList": {
"type":"array",
"eventDateItem": {
"type":"string",
"format":"date-time"
}
},
"eventDateStartTime": {
"type":"string",
"format":"date-time"
},
"eventDateEndTime": {
"type":"string",
"format":"date-time"
},
"eventTicket":{
"type":"array",
"eventTicketType":{
"type":"string"
},
"eventTicketLowPrice":{
"type":"number"
},
"eventTicketHighPrice":{
"type":"number"
},
"eventDatesAdvancePrice": {
"type":"number"
}
}
},
"performer": {
"performerID": {
"type":"integer"
},
"performerType": {
"type":"string"
},
"performerName": {
"type":"string"
},
"performerAlternateName": {
"type":"array",
"performerAlterateNameItem":{
"type":"string"
}
},
"performerGenreList": {
"type":"array",
"performerGenreItem":{
"type":"string"
}
},
"performerURL": {
"type":"string"
}
}
}
Ответы:
Я думаю, что ваш вопрос действительно сводится к: когда я должен использовать подход NoSQL против RDBMS? Вы рано остановились на JSON (решение NoSQL), возможно, потому, что у вас есть потребители Ajax.
Конечно, ответ на вопрос о том, когда использовать подходы NoSQL и RDBMS, заключается в том, с какими типами данных вы работаете и какие потребители ожидаете получить. Если ваши данные в основном реляционные (довольно плоские иерархии, нет странных типов данных, таких как изображения или аудио, предсказуемые отношения между схемами, которые можно легко описать в ключах), и ожидается, что ваши потребители в конечном итоге будут включать людей, которые хотят выполнять запросы Business Intelligence (специальные запросы), тогда СУРБД - это путь. Довольно просто превратить запрос в представление JSON, так что это не сильно отягощает ваших потребителей Ajax - он просто добавляет небольшое кодирование преобразования в ваши конечные точки (REST / SOAP / что угодно). НаоборотЕсли ваши данные очень иерархичны (глубокие схемы), содержат странные типы данных, такие как изображения, аудио, видео и т. д., между сущностями мало отношений, и вы знаете, что ваши конечные пользователи не будут заниматься бизнес-аналитикой, тогда NoSQL / хранение JSON может быть уместным.
Конечно, даже эти общие рекомендации не очень прочны. Причина, по которой Google разработал файловую систему Google, MapReduce (работа, которую Doug Cutting использовал для создания Hadoop в Yahoo), а затем и BigQuery (NoSQL-ориентированный [без схемы] способ управления крупномасштабными данными), заключалась именно в том, что у них было много специальных действий. BI запросы, и они не могли получить реляционные подходы для масштабирования до масштабов tera / peta / exa / zetta / yotta, которыми они пытались управлять. Единственный практический подход состоял в том, чтобы уменьшить масштаб, пожертвовав некоторым удобством пользовательского запроса, которое обеспечивает СУБД, и подставив простой алгоритм (MapReduce), который можно довольно легко кодировать для любого данного запроса.
Учитывая вашу схему выше, мой вопрос будет в основном: почему бы вам не использовать RDBMS? Я не вижу большой причины не делать этого. Предполагается, что наша профессия ориентирована на инжиниринг, а не на моду, поэтому наш инстинкт должен выбрать самое простое решение, которое работает, верно? Я имею в виду, что вашим конечным точкам, возможно, придется сделать небольшой перевод, если ваши потребители Ajaxy, но ваши данные выглядят очень плоскими, и вполне вероятно, что бизнес-пользователи захотят делать все виды специальных запросов на такие вещи, как музыкальные события (которые В прошлом году это событие было самым посещаемым в 50 милях от нашей столицы?)
«Не ходите к эльфам за советом, потому что они скажут и нет, и да». - Фродо
источник
Я считаю, что здесь есть и другие соображения, которые вы, возможно, не ищете Здесь есть две основные проблемы:
Место хранения
Существует множество мнений о том, почему использовать хранилище no-sql или RDBMS для ваших данных. Один из наиболее важных элементов, которые мы сочли полезными, заключается в том, что мы можем легко определять и хранить объекты json в хранилище, не беспокоясь об определении его полной структуры или взаимосвязи между различными типами объектов. Некоторые из других причин использования NoSql db - это возможность автоматического разделения данных, поиск по местоположению и простота обслуживания. Есть много хороших баз данных NoSql, мое личное предпочтение - MongoDB. Однако, если вы ранее не использовали базу данных NoSql, существует определенная кривая обучения, когда вы учитесь переосмысливать свой ум. Большинство из нас уже давно используют RDBMS, и для того, чтобы избавиться от этой привычки, требуются сознательные усилия. Кроме того, вы обнаружите, что хотите переделать свою модель данных, поскольку вы продолжаете свои усилия и лучше понимаете концепции. Если возможность рефакторинга или реконструкции не является вариантом для вашего проекта, я бы предложил придерживаться того, что вы уже знаете лучше всего.
Поиск
Если вы намереваетесь предоставить какой-либо вид поиска, который можно использовать, я настоятельно рекомендую вам использовать специальную систему текстового поиска, такую как SOLR, для выполнения поиска. Поиск текста идет медленно, и если у вас есть несколько осколков, то тем более медленный SOLR поддерживает быстрый быстрый текстовый поиск, включая взвешенные параметры поиска, поиск по местоположению и многое другое. SOLR, однако, не подходит в качестве основного хранилища ваших данных. Это означает, что вам придется создавать механизмы для двойной вставки и обновления как вашей основной базы данных, так и слоя SOLR при добавлении или обновлении событий. Кроме того, вам нужно будет позже обновлять SOLR, удаляя устаревшие / завершенные события.
Хотя это кажется большой дополнительной работой, вы поблагодарите себя за предусмотрительность использования полнотекстового поискового движка позже. Ни одна из баз данных NoSql или RDBMS не приблизилась к производительности и гибкости SOLR / Lucene.
источник
Во-первых, если вы пытаетесь хранить данные JSON в любом хранилище, но не в базе данных NoSQL , я определенно не рекомендую вам использовать JSON. Причина в том, что если вы храните ваши данные, например, в виде файла JSON, то его будет очень медленно открывать, анализировать, циклически просматривать и т. Д.
Прежде всего, я могу сузить ваш вопрос до: Каковы плюсы и минусы NoSQL и RDBMS ? И на него уже тысячи раз отвечали в сети.
Обновляя свой проект, вы, конечно, можете использовать либо NoSQL, либо RDBMS ; Однако, что я могу вам порекомендовать, так это думать нестандартно и искать другие менее заметные факторы, которые могут помочь вам выбрать один из двух вариантов. Попробуйте посмотреть, какой вариант может ускорить разработку? Что больше подходит для других членов команды - если вы не являетесь единственным разработчиком. Если вы продаете это, какой из них дешевле, проще и в целом больше подходит для ваших клиентов, не являющихся разработчиками?
Таким образом, вы можете, наконец, решить, какой путь выбрать, иначе будет действительно трудно решить, основываясь на данной информации, так как оба варианта вполне могут подойти.
источник
В большинстве приложений есть требования к
Чтобы выполнить требования для пункта 1, требуется метод сохранения данных. Как правило, если объем данных очень мал и тип данных прост и не требует обширных возможностей поиска, тогда можно использовать простую файловую структуру. По мере усложнения данных можно использовать структуру XML (или даже JSON) с данными, которые все еще хранятся в файлах. Однако поиск становится более проблематичным. По мере увеличения объема данных и увеличения сложности поиска обычно выбирается база данных, которая предоставляет стандартные отраслевые методы для сохранения данных, запросов и т. Д. Базы данных могут быть разработаны для обработки больших объемов данных, а также для быстрого и эффективного хранения, извлечения и поиска данных. ,
Чтобы выполнить требования для пункта 2, существуют различные методы обеспечения обмена данными между системами, включая XML, JSON и т. Д.
Эти методы позволяют пользователю определять структуру данных и не зависят от языка, что позволяет разнородной системе обмениваться данными.
В вашем конкретном случае вы правильно используете JSON для описания множества музыкальных событий. Хотя вы можете хранить данные в формате JSON, поиск этих данных по мере роста количества музыкальных событий будет медленным и неэффективным.
Используя подход с разделением интересов, лучше подходить к сбору данных, их сохранению в базе данных, выполнению запроса на основе пользовательского ввода в базу данных, а затем возвращать результаты в формате JSON на клиентскую сторону для отображения данных.
Дополнительная проблема с подходом JSON - это изменение структуры данных. В настоящее время ваша структура относительно проста. Вы можете использовать эту структуру в течение нескольких месяцев, а затем определяется дополнительное поле. Что вы тогда делаете со всеми вашими существующими объектами JSON? Обновлять их было бы проблематично.
Если вы используете базу данных, то добавление дополнительного поля является относительно простым, и только ваш код для генерации JSON должен быть изменен в одном месте, что даст вам новый JSON с новым полем.
Короче говоря, используйте каждый элемент технологии для того, для чего он был разработан для JSON для обмена данными и базы данных для сохранения данных.
источник
Я думаю, что вы будете иметь больший успех при использовании NoSQL, чем SQL для хранения этих данных, из-за запросов, которые вам нужно сделать.
Кроме того, просто потому, что некоторые данные являются чисто реляционными, это еще не значит, что они должны быть сохранены в некоторых СУБД (SQL). Реляционные данные IMO лучше переведут в графовые базы данных.
Конечно, вы также можете писать запросы в SQL, но производительность будет ужасной из-за количества соединений, которые вам понадобятся (учитывая, что ваши данные будут несколько нормализованы, а не все из них в одну таблицу событий).
Но в заключение вы получите больше свободы при использовании NoSQL (таким образом, JSON или другого формата, поддерживаемого базой данных), учитывая, что вы можете изменить свою схему в будущем без учета уже сохраненных данных.
Рассматривая NoSQL, вы также можете изучить графовые базы данных, если планируете использовать очень сложные запросы, так как они дадут вам преимущества в их простом создании и быстром выполнении.
источник
Я думаю, что вы должны использовать оба, и я не рассматриваю это как решение "против".
Реляционная база данных имеет смысл для быстрого и эффективного хранения и извлечения данных, которые имеют реляционные свойства.
JSON - отличный формат данных, потому что он прост, легок и идеален для передачи необработанных данных в очень простом формате с синтаксисом, подходящим для хранения и обмена текстовой информацией. Он отлично подходит для передачи небольших объемов данных между браузером и сервером. Это не такой простой формат, чтобы начать использовать его для запросов данных реляционного типа.
Поэтому я бы порекомендовал SQL для хранения данных и JSON для формата передачи данных.
Это правда, что нет опций значения ключа noSQL, таких как Mongo, Redis и т. Д. Они могут иметь преимущество, возможно, в более простом отображении в формат JSON, но, как правило, его немного сложнее использовать для запросов. Основным препятствием для них является незнакомство со стороны общего ИТ-сообщества, особенно по сравнению с SQL, который так хорошо известен и обладает огромным массивом ресурсов и знаний, доступных практически для любой мыслимой ситуации.
источник