Основные сведения о различиях между NoSQL и реляционными базами данных

ПРИМЕНИМО К: API SQL API Cassandra API Gremlin API таблиц API Azure Cosmos DB для MongoDB

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

Высокая пропускная способность

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

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

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

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

Серверная часть

Иерархические данные

В ряде случаев транзакции в базе данных содержат множество связей между родительскими и дочерними элементами. Количество этих связей может значительно увеличиваться со временем, что гарантированно осложняет управление. Формы иерархических баз данных были созданы еще в 1980-е годы, но не пользовались популярностью, так как не обеспечивали эффективное хранение данных. Интерес к ним был полностью утрачен, когда фактическим стандартом стала реляционная модель Эдгара Кодда, которую использовали практически все основные системы управления базами данных.

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

Появление объектно-ориентированного проектирования и рассогласование интерфейсов, возникающее при объединении его с реляционными моделями, также выявляет недостатки реляционных баз данных при определенных вариантах использования. Результатом могут стать скрытые, но часто весьма существенные дополнительные затраты на обслуживание. И хотя изменение подходов к объектно-реляционному отображению (ORM) позволило частично устранить эту проблему, однако документноориентированные базы данных гораздо лучше сочетаются с объектно-ориентированными методами. При таком подходе разработчики не привязаны к драйверам ORM или ядрам объектно-ориентированных СУБД, использующим специальные языки. Если данные содержат много связей между родительскими и дочерними объектами и уровней иерархии, можно ввести в действие базу данных документов NoSQL, например API SQL Azure Cosmos DB.

OrderDetails

Сложные сети и связи

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

Наряду с появлением реляционных баз данных возникли различные формы “сетевых” БД, но, как и в случае с иерархическими базами данных, эти системы с трудом пробивали себе дорогу. Нежелание их внедрять объяснялось недостатком вариантов использования и неэффективностью в плане хранения данных. В наше время модели графовых баз данных можно рассматривать как второе рождение парадигмы сетевой базы данных. Ключевым преимуществом этих систем является то, что связи хранятся в базе данных как “VIP-объекты”. Поэтому обход связей занимает фиксированный отрезок времени, который не увеличивается из-за того, что сложность связей повышается при присоединении нового продукта или взаимодействии с ним.

Если в вашей базе данных поддерживается сложная сеть связей, вы можете рассмотреть возможность внедрения графовой базы данных, такой как API Gremlin Azure Cosmos DB , для управления этими данными.

На диаграмме базы данных отображается несколько сотрудников и отделов, соединенных друг с другом.

Azure Cosmos DB — это служба баз данных, использующая несколько моделей. Она предоставляет проекцию API для всех основных типов моделей NoSQL: “семейство столбцов”, “документноориентированная”, “графовая” и “ключ-значение”. Уровни API документов Gremlin (графовая БД) и SQL (ядро) полностью совместимы. Это дает преимущества при переходе между различными моделями на уровне программирования. Запросы к хранилищам графов можно отправлять как для сложных обходов сети, так и для транзакций, смоделированных как записи документов в том же хранилище.

Гибкая схема

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

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

Микрослужбы

В последние годы значительно выросла популярность микрослужб, что обусловлено сервисноориентированной архитектурой. Фактическим стандартом передачи данных в современных архитектурах микрослужб является JSON, который одновременно выполняет роль носителя для подавляющего большинства документноориентированных баз данных NoSQL. Благодаря этому хранилища документов NoSQL гораздо лучше обеспечивают сохраняемость и синхронизацию (с использованием шаблонов источников событий) в сложных реализациях микрослужб. Часто в таких архитектурах гораздо труднее поддерживать более традиционные реляционные базы данных. Это связано с большим числом преобразований, необходимых для состояния и синхронизации между API. В частности, Azure Cosmos DB располагает рядом функций, благодаря которым она сочетается с архитектурами микрослужб на основе JSON даже лучше, чем многие базы данных NoSQL:

  • набор чистых типов данных JSON;
  • подсистема JavaScript и API запросов, встроенные в базу данных;
  • прогрессивный канал изменений, на который клиенты могут подписаться, чтобы получать уведомления об изменениях в контейнере.

Проблемы при работе с базами данных NoSQL

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

  • транзакции с множеством связей, указывающих на одну и ту же сущность;
  • транзакции, для которых необходима строгая согласованность во всем наборе данных.

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

Joins

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

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

Базы данных NoSQL дают более гибкие возможности для устранения таких недостатков, но больше гибкости означает больше проектных решений. Ознакомьтесь со статьей Моделирование и секционирование данных в Azure Cosmos DB на практическом примере. В примере описывается подход к синхронизации денормализованных данных пользователя в условиях, когда пользователи используют не только разные разделы, но и в разные контейнеры.

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

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

Дальнейшие действия

Узнайте, как управлять учетной записью Azure Cosmos, и ознакомьтесь с другими концепциями: