Есть ли что-то новаторское в NoSQL? [закрыто]

Я очень солидный парень по реляционной базе данных и понимаю, вплоть до 3-й нормальной формы, ценю корни алгебраической теории множеств в SQL и, вероятно, могу реляционизировать разбитое сердце (или нет).

Я не разобрался со структурой реляционных баз данных для вечеров свиданий с женой, но я думал о проектах реляционных баз данных на вечерах свиданий с женой.

Сейчас я слышу о NoSQL и исследую его. Если говорить о погоне, то есть ли в NoSQL что-то новаторское, математически новое или «эй, вам даже не нужно организовывать ваши данные реляционно, это намного проще»?

Является ли NoSQL супер оболочкой для структуры данных? На мой взгляд, в конечном итоге данные должны иметь структуру для извлечения, а поиск должен быть определен на каком-то языке.

NoSQL скорее эволюционный, чем революционный. Он по существу объединяет существующие идеи «внешнего хранилища базы данных» с «использованием знакомых структур данных, а не реляционных таблиц».

Существует больше типов баз данных, чем реляционных, например, иерархические базы данных . Хотя архаичный по сегодняшним меркам, он действительно хорошо сочетается со структурами данных своих данных (например, записями COBOL ). Дело в том, что данные в базе данных были смоделированы в соответствии с тем, как были размещены записи на языках программирования, которые их использовали.

Перейдем к изобретению реляционных баз данных , где, наконец, база данных разделена между интересами и, при правильной нормализации, является отличным способом визуализации большинства типов данных и связей между данными. Это действительно легко понять по сравнению с другими типами баз данных. Однако он не может хранить данные таким образом, чтобы они отражали объекты и классы в программе. Отсюда и изобретение объектно-реляционного отображения . Другими словами, дизайн базы данных на самом деле является помехой для дизайна программы, которая ее использует, поэтому нам нужны библиотеки ORM, такие как Hibernate., Будучи чистым и последовательным, в глубине моего сознания всегда возникает ноющее сомнение, что что-то здесь не совсем так.

Это дало начало еще двум типам баз данных, объектным базам данных и NoSQL .

Оба пытаются решить проблемы, связанные с реляционными базами данных, не подвергая нас ужасным ужасам иерархических баз данных. Данные по-прежнему размещаются в репозиториях, которые неопределенно напоминают таблицы, но в действительности они больше похожи на программирование структур данных, чем на реляционные таблицы. В то время как объектные базы данных следуют в основном четко определенным правилам, я понимаю, что NoSQL довольно произвольный. Например, таблица может быть визуализирована как хеш-таблица или массив. Не существует простого, четко определенного способа запроса к ним с использованием произвольного инструмента, аналогичного Oracle SQL Developer или SQL Server Management Studio .

Идея состоит в том, что можно определить структуры данных, которые легко искать в коде, вместо того, чтобы соединять вместе запросы SQL, которые лучше подходят для механизма баз данных SQL, а не выражать запрос, который желателен. Например, нечеткие или частичные совпадения более сложны и работают хуже в реляционной базе данных, в то время как база данных NoSQL может иметь структуру, которая оптимизирована для такого поиска и завершается за долю времени.

Есть языки для запросов NoSQL. Однако нет универсального языка, такого как SQL для реляционных баз данных.

Позднее редактирование:

Хотя я достаточно хорошо знаком с базами данных NoSQL, этот вопрос стал для меня стимулом купить качественную книгу по этой теме и начать ее чтение с конечной целью стать настоящим экспертом по этой теме. Остальные комментарии основаны на NoSQL Distilled: краткое руководство по формирующемуся миру устойчивости Полиглота, разработанное Прамодом Садалажем и Мартином Фаулером .

Авторы утверждают, что реляционные базы данных плохо масштабируются до кластеров, способных обслуживать данные, необходимые для таких сайтов, как Amazon и Google: NoSQL был разработан для соответствия этой нише, ослабляя параллелизм и долговечность в ACID для того, чтобы обслуживать большое количество запросов, которые в основном используют статические данные (следовательно, транзакции ACID не так важны).

Кроме того, они утверждают, что базы данных NoSQL работают без схемы (стр. 10), которая позволяет базам данных NoSQL более легко изменять структуру данных. Я не уверен, что наличие или отсутствие формальной схемы имеет значение в этом отношении, так как базы данных SQL также позволяют изменять схемы. Несмотря на это, два известных автора предъявляют претензии, так что их стоит изучить.

Я полагаю, что оба эти основных момента служат только для того, чтобы убедить меня в том, что NoSQL является эволюционным, а не революционным. Они по-прежнему хранят данные и постепенно улучшают масштаб и модифицируемость. Они также подчеркивают, что NoSQL не стремится узурпировать реляционные базы данных как короля хранилища данных, а только предоставляет альтернативные средства хранения данных для типов данных, которые должны масштабироваться и изменяться таким образом, который (по их мнению) реляционный базы данных не поддерживают достаточно хорошо.

Я думаю, что вы определенно хотели бы взглянуть на эту статью Erik Meijer & Gavin Bierman, озаглавленную «Вопреки распространенному мнению, SQL и NoSQL - это на самом деле просто две стороны одной медали» . Короче говоря, он утверждает, что математически говоря оба подхода основаны на одной и той же теории, но с некоторыми отличиями.

Несколько интересных отличий, на мой взгляд, следующие: направление перекрестных зависимостей (FK в SQL) является противоположным в SQL и NoSQL, а тип коллекций не ограничивается набором в NoSQL (и, следовательно, некоторыми теоретико-множественными операциями может больше не применяться в мире NoSQL, но некоторые другие все еще действуют). Еще один интересный момент из этой статьи - это один язык запросов, предлагаемый для запросов к базам данных как SQL, так и NoSQL. Он называется LINQ, и если вы думаете, что слышали это имя раньше, вы правы: это язык запросов Microsoft из C #.

Ответ Сноумана правильно описывает, как SQL и NoSQL различаются по своим структурам данных и как к ним осуществляется доступ. Однако, возможно, еще более важным отличием является их соответствующая проблемная область.

NoSQL не является преемником SQL. Скорее, различные ветви NoSQL жертвуют одними качествами SQL, чтобы быть лучше других . Теорема CAP гласит, что ни одна распределенная система баз данных не может удовлетворить все следующие свойства:

• консистенция
• Доступность
• Допуск раздела

Таким образом, некоторые варианты NoSQL следуют принципу BASE , который ослабляет ограничение всегда полной согласованности ACID , которое является основой для классических баз данных SQL. Потеряв некоторые гарантии согласованности, они получают возможность сочетать высокую доступность и устойчивость к разделам в широко распространенных системах, таких как веб-сайты с большими объемами данных и пользовательскими запросами, но небольшим спросом на идеальную согласованность. Таким образом, такие базы данных NoSQL находятся в центре Google , Facebook и Amazon . Итак, чтобы ответить на ваш вопрос: да, NoSQL является новаторским в том смысле, что он в значительной степени поддерживает такие массивные веб-сервисы.

Это только один пример, поскольку NoSQL - это разнообразное поле, и его варианты охватывают практически все возможные комбинации параметров в треугольнике CAP .

Распространенные случаи использования NoSQL являются революционными в плане повышения производительности по сравнению с обычными базами данных на основе SQL. Есть несколько факторов в этом.

Одним из них является ведение домашнего хозяйства. Большинство NoSQLs имеют открытый исходный код и могут быть установлены на рабочей станции или виртуальной машине с помощью нескольких команд и работают с приемлемыми стандартными настройками по умолчанию. По моему опыту, даже Postgres и MySQL не такие; Конфигурация обычно необходима, чтобы начать работу даже на рабочей станции в целях разработки.

Еще одна удобная разработка, так как другие ответы подробно описаны. Возможности индексирования JSON в Mongo, или семантика ключ / значение в redis и Riak, могут быть всеми необходимыми веб-приложениями для выполнения работы, а API-интерфейсы просты. Некоторые NoSQL предоставляют свои собственные API-интерфейсы RESTful, тогда как с SQL вы обычно пишете их самостоятельно.

Эти факторы делают базы данных NoSQL привлекательными для небольших проектов. Время погрузки, как правило, мало. Конечно, когда вы отправляетесь в производство, вам необходимо настроить безопасность и масштабирование, но способность быстро приступить к написанию кода и совместной работе является мощной и, я полагаю, новаторской.

Кроме того, в связи с вышеизложенным, для небольших приложений (таких как внутренние компании или сервисы от приложения к приложению) команда может быть в состоянии поддерживать производственную базу данных NoSQL без привлечения своих команд DBA и без потери производительности или целостности. проблемы в результате. Профессиональным администраторам баз данных это может не понравиться, но разработчики, которые рассматривают администраторов баз данных как источник препятствий (правильных или неправильных), иногда рассматривают NoSQL как способ избежать необходимости иметь дело с ними. Признаюсь в этом - однажды я изменил мелкомасштабное приложение с Postgres на SQLite, чтобы исключить соперничающего администратора баз данных, и я решил внедрить его в Mongo, а не в Oracle, чтобы избежать процессов утверждения DBA и ограничений доступа. Без отрицательных последствий в любом случае.