Реляционные базы данных или NoSQL?

За последние несколько лет в технологии баз данных произошли большие изменения. Традиционные реляционные базы данных остаются популярными и их важными характеристиками являются табличные структуры данных и механизм проведения транзакций (ACID-транзакции: Atomicity, Consistency, Isolation, Durability — атомарность, согласованность, изолированность, долговечность).

В системах баз данных NoSQL («не SQL» или «не только SQL») данные представлены в формах, отличных от реляционных таблиц. В частности, как системы управления документами: хранилища типа «ключ — значение», столбцовые хранилища и базы данных работы с графами. Большинство из этих баз данных жертвуют согласованностью в пользу доступности, масштабируемости и устойчивости к разделению сети. 

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

Теореме CAP (Consistency, Availability, Partition tolerance — согласованность, доступность, устойчивость к разделению) гласит, что для распределенных хранилищ данных невозможно гарантировать более двух из трех ограничений: Consistency, Availability, Partition tolerance — согласованность, доступность, устойчивость к разделению.

Поскольку распределенные сети не являются надежными (устойчивыми к разделению), то можно выбирать, будет ли система гарантировать согласованность или горизонтальную масштабируемость. Большинство баз данных NoSQL предпочитают масштабируемость, жертвуя согласованностью.

Причина использования систем NoSQL кроется в недостатках реляционных баз данных. Самая большая проблема реляционных баз данных, поддерживающих ACID, заключается в невозможности горизонтального масштабирования.

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

Тем не менее реляционные базы данных довольно хорошо подходят для большинства корпоративных приложений. Если же требуется горизонтальное масштабирование и централизованная база данных больше не подходит, можно разделить хранилище, воспользовавшись такой технологией, как событийно-ориентированная архитектура. А у баз данных NoSQL есть недостатки, связанные с поддержкой транзакционной семантики.

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

Пока ни одна система NoSQL не стала фактическим стандартом. Многие из них сильно различаются по концепциям и практике применения. Не существует также стандартной NoSQL, например, включенной в комплект Java EE 8. Поэтому доступ к системам NoSQL обычно реализуется с использованием API от сторонних поставщиков.