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

Некоторые из ключевых преимуществ использования реляционной базы данных:

  • Атомарность, Последовательность, Изолированность и Надежность. (я не большой любитель аббревиатур)
  • Схема базы данных (таблица, столбцы, строки и типы)
  • SQL
  • Возможность получать специальные отчеты для руководства — это самая любимая функция «предприятий».

Итак, с какой стати нам понадобился другой тип базы данных?

Несоответствие импеданса

Взгляните на типичный вид страницы заказа, сводку заказа, если хотите.

Между тем, как мы храним данные в реляционной БД и представляем их на экране, существует неразрывность. Данные, которые мы отображаем на странице, извлекаются из нескольких таблиц, некоторые из которых могут быть даже разбросаны по разным экземплярам баз данных. Это явление называется несоответствие импеданса. Фреймворки ORM в определенной степени помогают нам преодолеть этот разрыв. Тем не менее есть пробел.

Увеличение масштаба имеет свои ограничения

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

Добавьте облако в микс

С самого начала у облака была идея иметь фермы серверов или использовать обычное оборудование вместо (или в дополнение) к меньшему количеству высокопроизводительных машин. Люди, работающие в технологических гигантах, таких как Google и Amazon, поняли это и начали работать над хранилищем данных, которое по своей сути было создано для хранения данных на нескольких узлах. Google придумал Big Table, а Amazon — Dynamo. Промышленность постепенно подхватила этот тренд, и так появились базы данных NoSQL. Мало того, что они просто появились, рост облачной поддержки способствовал массовому использованию баз данных NoSQL.

Обещания NoSQL

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

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

  • Вы можете выбрать только 2 функции из Consistency, Availability, Partition Tolerance, также известных как. Теорема САР
  • Создание различных представлений из уже сохраненных данных является сложной задачей и требует пользовательского кода.

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

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