2.10 No sql бд и субд

В течение многих десятилетий, выбор многих разработчиков и системных администраторов для их приложений всегда падал на реляционные СУБД. Несмотря на то, что они не такие уж и адаптивные, функционал реляционных СУБД позволял создавать довольно сложные системы данных. Этого было более чем достаточно, пока в конце 2000, не появились NoSQL СУБД.

Сам термин NoSQL сначала был названием очередной реляционной системы управления базами данных и подразумевал попытку избежать использования стандартов SQL. Затем другие производители ПО в области БД подхватили эту идею и стали использовать этот термин в отношении всех нереляционных баз данных.

Стоит подчеркнуть, что термин “NoSQL” имеет абсолютно стихийное происхождение и не имеет общепризнанного определения или научного учреждения за спиной. Это название скорее характеризует вектор развития ИТ в сторону от реляционных баз данных. Расшифровывается как Not Only SQL.

Характеристики NoSQL баз данных:

1. NoSql базы в-основном оупенсорсные и созданы в 21 столетии.

2. Не используется SQL .Имеется в виду ANSI SQL DML, так как многие базы пытаются использовать query languages похожие на общеизвестный синтаксис, но полностью его реализовать не удалось никому и вряд ли удастся.

3. Неструктурированные (schemaless) . В NoSQL базах в отличие от реляционных структура данных не регламентирована (или слабо типизированна, если проводить аналогии с языками прогаммирования) — в отдельной строке или документе можно добавить произвольное поле без предварительного декларативного изменения структуры всей таблицы. Таким образом, если появляется необходимость поменять модель данных, то единственное достаточное действие — отразить изменение в коде приложения. 

Положительное следствие отсутствия схемы — эффективность работы с разреженными (sparse) данными. Если в одном документе есть поле date_published, а во втором — нет, значит никакого пустого поля date_published для второго создано не будет.

У неструктурированной схемы есть свои недостатки — помимо накладных расходов в коде приложения при смене модели данных — отсутствие всевозможных ограничений со стороны базы (not null, unique, check constraint и т.д.), также возникают дополнительные сложности в понимании и контроле структуры данных при параллельной работе с базой разных проектов (отсутствуют какие-либо словари на стороне базы). Впрочем, в условиях быстро меняющегося современного мира такая гибкость является все-таки преимуществом.

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

Плюсы и минусы обоих подходов представлены в таблице:

Таблица

Нормализация данных	Агрегированные данные
Плюсы: целостность информации при обновлении за счет обновления записи только в одной таблице; ориентированность на широкий спектр запросов к данным.	Минусы: оптимизация только под определенный тип запросов; сложности при обновлении денормализованных данных
Минусы: неэффективна в распределенной среде; низкая скорость чтения при использовании соединений (join); несооответствие объектной модели приложения физической структуре данных (impedance mismatch, котторая может быть решена, например использованием библиотеки Hipernate и т.п.	Плюсы: большая скорость на чтение в распределенной среде; возможность физически хранить объекты в том виде, в котором они используются в приложении и, следовательно, легче кодировать и меньше ошибок при преобразовании; собственная (native) поддержка атомарности на уровне записи.

5. Слабые ACID свойства. Долгое время консистентность (consistency) данных была «священной коровой» для архитекторов и разработчиков. Все реляционные базы обеспечивали тот или иной уровень изоляции — либо за счет блокировок при изменении и блокирующего чтения, либо за счет undo-логов. С приходом огромных массивов информации и распределенных систем стало ясно, что обеспечить для них транзакционность набора операций с одной стороны и получить высокую доступность и быстрое время отклика с другой невозможно.

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