NoSQL: виды, особенности и применение

Уже само название заявляет, что управлять данными можно не только с помощью Structured Query Language (SQL), т. е. языка структурированных запросов.

Модель NoSQL появилась в ответ на необходимость оперативно обрабатывать действительно огромные объёмы данных. Поэтому NoSQL по большей части заточена под масштабирование по горизонтали и работу с недостаточно структурированными или постоянно меняющимися данными.

Почему появилась модель NoSQLПочему появилась модель NoSQL

Расцвет реляционных (relation — «связь, взаимосвязь») баз данных пришёлся на 80-е годы, когда в БД в основном хранили текстовые документы и изображения. Однако с развитием технологий и ростом объёма обрабатываемой информации реляционные СУБД перестали справляться со всеми задачами одинаково хорошо. Термин NoSQL впервые прозвучал в 1998 году: его применил итальянский учёный Карло Строцци для описания своей open source СУБД. При разработке он отказался от SQL, а также от основного принципа реляционных СУБД — ACID (atomicity, consistency, isolation, durability).

В начале XXI века NoSQL БД стали популярны, в том числе у корпораций. Чтобы решить проблемы параллельных вычислений с очень большим объёмом информации и масштабируемости, Google построила на основе модели распределённых вычислений MapReduce колоночное хранилище. На базе этих технологий выросло целое семейство высокодоступных open source СУБД.

Основные причины появления NoSQL:

SQL vs. NoSQL: в чём разницаSQL vs. NoSQL: в чём разница

УправлениеУправление

Работа с реляционной базой строится на общепринятом языке SQL. У NoSQL СУБД нет единого стандарта: у каждой такой базы индивидуальный подход к записи, хранению и извлечению данных. Поиск информации может вестись, например, по парам «ключ — значение» или по наборам столбцов.

СтруктураСтруктура

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

СУБД без SQL позволяют записывать и получать неструктурированную информацию, дают возможность менять схемы и запросы в соответствии с требованиями к данным. Когда речь идёт о работе с time-series data, информацией без взаимосвязи, о хранении документов с разной структурой и высокой степенью вложенности, то именно NoSQL показывают большую скорость и производительность.

ACID-транзакцииACID-транзакции

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

• система обеспечивает базовую доступность (Basic Availability), т. е. каждый запрос будет обязательно завершён, успешно или нет;

• система пребывает в гибком состоянии (Soft-state) — очерёдность записей соблюдать необязательно, реплики могут какое-то время находиться в несогласованном состоянии, а система может самостоятельно изменяться для достижения согласованности;

• все данные всё равно достигнут согласованности (Eventual Consistency).

Плюсы NoSQLПлюсы NoSQL

Гибкость модели данныхГибкость модели данных

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

Доступность данныхДоступность данных

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

Лучшая масштабируемостьЛучшая масштабируемость

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

Высокая производительностьВысокая производительность

Благодаря оптимизации баз под определённые виды моделей данных скорость представления информации часто превосходит скорость SQL-базы. Например, если необходимые записи хранятся в одном документе, больше нет потребности в операции JOIN. Это упрощает процесс, когда необходимо провести аналитику над данными, агрегацию или расчёты внутри сущности.

Экономия ресурсовЭкономия ресурсов

Горизонтальное масштабирование позволяет сократить количество дорогостоящих серверов. А поскольку большинство NoSQL являются open source проектами, можно экономить на подписке и поддержке. Или развернуть и эксплуатировать базы данных в облачном сервисе: NoSQL благодаря распределённости и горизонтальной масштабируемости прекрасно для этого подходят.

Yandex Cloud, например, предлагает сервисы для управления нереляционными базами данных: MongoDB, Redis^™, Elasticsearch, ClickHouse.

Для каких задач подходят NoSQL базы данныхДля каких задач подходят NoSQL базы данных

Если реляционные СУБД на протяжении многих лет были универсальным решением, то с развитием NoSQL у разработчиков появился выбор: теперь базы данных реально подобрать под конкретные задачи.

NoSQL-СУБД различаются моделями данных, а также подходом к распределённости и репликации. Выделяют четыре основные категории нереляционных БД.

Базы данных по принципу «ключ — значение» (key-value store)Базы данных по принципу «ключ — значение» (key-value store)

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

Key-value СУБД часто используется для систем, в которых скорость является приоритетом, а данные не слишком сложные. Например, для хранения кеша данных, онлайн-списков, обработки истечения срока действия, разделения сеансов, построения рейтинга и прочих задач.

Яркий пример key-value store БД — Redis. Ей пользуются Airbnb, Slack, Twitter и Uber. Система целиком работает в оперативной памяти, что позволяет информации считываться и записываться намного быстрее, чем даже на очень шустрые твердотельные накопители.

Колоночные базы данных (column family store)Колоночные базы данных (column family store)

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

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

В этой категории существуют базы ClickHouse, Vertica, Cassandra и другие. Netflix, например, использует в том числе хранилище Cassandra: база легко масштабируется, и у неё нет единых точек отказа.

Yandex предлагает поддержку в развёртывании кластера аналитической базы данных ClickHouse. Эта СУБД создавалась под требования Яндекс Метрики — веб-аналитического инструмента, которому необходимо максимально быстро выполнять запросы, обрабатывать данные в реальном времени и хранить петабайты информации. ClickHouse отвечает всем этим требованиям и поэтому активно используется для внутренней аналитики, аналитики веб-проектов и мобильных приложений и мониторинга инцидентов в сервисах.

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

Преимуществами ClickHouse уже пользуются OZON, Райффайзен Банк, S7 Airlines. Социальная сеть ВКонтакте использует эту СУБД для хранения и чтения отладочных логов, у eBay в ClickHouse хранятся журналы, метрики и события. В Яндексе на этой колоночной базе данных работают электронная почта, Яндекс Маркет, Яндекс Метрика, Яндекс Директ и Яндекс Вебмастер.

Документоориентированные базы данных (Document-oriented store)Документоориентированные базы данных (Document-oriented store)

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

Document-oriented-модель хороша в проектах, где нужно обрабатывать большой объём данных без четкой структуры, а также для работы со множеством уникальных документов, которые со временем требуют изменений. Например, для каталогов товаров, соцсетей, платформ с блогами и видео, геоаналитики и в других сферах.

Гибкость MongoDB даёт широкий выбор способов моделирования данных. Такая модель облегчает хранение массивов и других сложных структур. Ориентированная на документы база данных прекрасно показывает себя при большом потоке запросов в реальном времени, поэтому может стать частью социальной сети. Также она подойдёт для кеширования данных и создания брокера очередей. И всё это вкупе с отказоустойчивостью, простым масштабированием за несколько минут и высокими показателями безопасности данных.

Графовые базы данных (graph store)Графовые базы данных (graph store)

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

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

Для доступа к таким БД необходим язык запросов, но, поскольку общепринятых стандартов у NoSQL нет, для разных типов графовых баз данных понадобится индивидуальный подход. К графовым относятся базы данных Neo4j, OrientDB.

Как выбрать базу данныхКак выбрать базу данных

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

Выбрать NoSQL стоит в тех случаях, когда:

• нужно хранить большие объёмы неструктурированных или быстро меняющихся данных;

• нет возможности описать схему СУБД до начала проектирования базы данных или предполагается, что в процессе работы архитектура хранилища будет меняться;

• необходимо быстро без большой предварительной подготовки запустить прототип продукта;

• требуется высокая масштабируемость системы без лишних ресурсозатрат;

• строгой согласованностью можно пожертвовать ради производительности и доступности.

NoSQL в Yandex CloudNoSQL в Yandex Cloud

Чтобы подобрать хранилище NoSQL, сначала желательно определиться с моделью данных, которая требуется бизнесу. Yandex Cloud предлагает полный цикл обработки данных любого типа — от сбора и хранения до анализа и визуализации. Для этого на платформе развёрнуты сервисы управления несколькими видами нереляционных БД: Redis, MongoDB, Elasticsearch.

Yandex Cloud использует последние стабильные версии систем и регулярно следит за обновлениями. Тратить много времени на обслуживание базы данных на Yandex Cloud тоже не придётся: архитекторы и программисты занимаются резервированием, мониторингом, обеспечением отказоустойчивости и обновлением ПО.