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

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

Эволюция NoSQL

Проблема масштабируемости SQL была признана компаниями Web 2.0 с огромными, растущими потребностями в данных и инфраструктуре, такими как Google, Amazon и Facebook. Они придумали собственные решения проблемы — такие технологии, как BigTable, DynamoDB и Cassandra.

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

Во-первых, были проприетарные (с закрытым исходным кодом) типы баз данных NoSQL, разработанные крупными компаниями для удовлетворения их конкретных потребностей, такие как BigTable от Google, которая считается первой системой NoSQL, и DynamoDB от Amazon.

Успех этих проприетарных систем инициировал разработку ряда аналогичных систем баз данных с открытым исходным кодом и проприетарных систем, наиболее популярными из которых являются Hypertable, Cassandra, MongoDB, DynamoDB, HBase и Redis.

Что отличает NoSQL?

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

Это означает, что базы данных NoSQL не имеют фиксированной структуры таблиц, как в реляционных базах данных.

Преимущества и недостатки баз данных NoSQL

Преимущества

Базы данных NoSQL имеют много преимуществ по сравнению с традиционными реляционными базами данных.

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

В отличие от реляционных баз данных, базы данных NoSQL основаны на парах ключ-значение.

Некоторые типы хранилищ баз данных NoSQL включают хранилище столбцов, хранилище документов, хранилище значений ключей, хранилище графов, хранилище объектов, хранилище XML и другие режимы хранения данных.

Обычно каждое значение в базе данных имеет ключ. Некоторые хранилища баз данных NoSQL также позволяют разработчикам хранить в базе данных сериализованные объекты, а не только простые строковые значения.

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

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

Недостатки

Конечно, базы данных NoSQL не идеальны, и они не всегда являются правильным выбором.

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

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

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

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

NoSQL против реляционных баз данных

В этой таблице представлено краткое сравнение функций NoSQL и реляционных баз данных:

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

Типы хранилищ данных NoSQL

Хранилище ключевых значений

В типе хранилища Key Value используется хэш-таблица, в которой уникальный ключ указывает на элемент.

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

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

Все, что необходимо для работы с элементами, хранящимися в базе данных, — это ключ. Данные хранятся в виде строки, JSON или BLOB (большой двоичный объект).

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

Самая известная база данных NoSQL, построенная на основе хранилища ключей и значений, — DynamoDB от Amazon.

Магазин документов

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

Однако между ними есть ключевые различия.

В хранилищах документов значения (документы) обеспечивают кодировку хранимых данных. Эти кодировки могут быть XML, JSON или BSON (JSON с двоичным кодированием).

Кроме того, можно выполнять запросы на основе данных.

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

Хранилище колонок

В базе данных Column Store данные хранятся в столбцах, а не в строках, как это делается в большинстве систем управления реляционными базами данных.

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

Хранилища столбцов имеют быстрый доступ для чтения/записи к сохраненным данным. В хранилище столбцов строки, соответствующие одному столбцу, сохраняются как одна запись на диске. Это обеспечивает более быстрый доступ во время операций чтения/записи.

К наиболее популярным базам данных, использующим хранилище столбцов, относятся Google BigTable, HBase и Cassandra.

База графика

В базе данных Graph Base NoSQL для представления данных используется структура ориентированного графа. Граф состоит из ребер и узлов.

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

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

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

В настоящее время InfoGrid и InfiniteGraph являются самыми популярными графовыми базами данных.

Системы управления базами данных NoSQL

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

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

Другие системы баз данных NoSQL, такие как Apache CouchDB, также являются базами данных типа хранилища документов и имеют много общих функций с MongoDB, за исключением того, что доступ к базе данных можно получить с помощью RESTful API.

REST — это архитектурный стиль, состоящий из скоординированного набора архитектурных ограничений, применяемых к компонентам, соединителям и элементам данных во Всемирной паутине. Он основан на кэшируемом клиент-серверном протоколе связи без сохранения состояния (например, протоколе HTTP).

Приложения RESTful используют HTTP-запросы для отправки, чтения и удаления данных.

Что касается баз данных столбцов, Hypertable — это база данных NoSQL, написанная на C++ и основанная на Google BigTable.

Hypertable поддерживает распределение хранилищ данных между узлами для максимальной масштабируемости, как MongoDB и CouchDB.

Одной из наиболее широко используемых баз данных NoSQL является Cassandra, разработанная Facebook.

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

Вместо подробного рассмотрения каждой СУБД NoSQL в следующих подразделах будут рассмотрены две наиболее широко используемые системы управления базами данных NoSQL — Cassandra и MongoDB.

Кассандра

Cassandra — это система управления базами данных, разработанная Facebook.

Целью Cassandra было создание СУБД, не имеющей единой точки отказа и обеспечивающей максимальную доступность.

Cassandra — это в основном база данных хранилища столбцов. В некоторых исследованиях Cassandra упоминается как гибридная система, вдохновленная BigTable от Google, которая представляет собой базу данных с хранилищем столбцов, и DynamoDB от Amazon, которая представляет собой базу данных с ключом и значением.

Это достигается за счет предоставления системы «ключ-значение», но ключи в Cassandra указывают на набор семейств столбцов с опорой на распределенную файловую систему Google BigTable и функции доступности Dynamo (распределенная хеш-таблица).

Cassandra предназначена для хранения огромных объемов данных, распределенных по разным узлам. Cassandra — это СУБД, предназначенная для обработки огромных объемов данных, распределенных по множеству серверов, при этом обеспечивая высокодоступный сервис без единой точки отказа, что очень важно для такого крупного сервиса, как Facebook.

К основным особенностям Кассандры относятся:

• Отсутствие единой точки отказа. Для этого Cassandra должна работать на кластере узлов, а не на одной машине. Это не означает, что данные в каждом кластере одинаковы, но программное обеспечение для управления одинаково. Когда происходит сбой в одном из узлов, данные на этом узле будут недоступны. Однако другие узлы (и данные) по-прежнему будут доступны.
• Распределенное хеширование — это схема, обеспечивающая функциональность хеш-таблицы таким образом, что добавление или удаление одного слота не приводит к существенному изменению сопоставления ключей со слотами. Это дает возможность распределять нагрузку на серверы или узлы в соответствии с их мощностью и, в свою очередь, минимизировать время простоя.
• Относительно простой в использовании клиентский интерфейс . Cassandra использует Apache Thrift для своего клиентского интерфейса. Apache Thrift предоставляет многоязычный RPC-клиент, но большинство разработчиков предпочитают альтернативы с открытым исходным кодом, созданные поверх Apple Thrift, такие как Hector.
• Другие функции доступности. Одной из возможностей Cassandra является репликация данных. По сути, он зеркалирует данные на другие узлы в кластере. Репликация может быть случайной или специфичной для максимальной защиты данных, например, путем размещения узла в другом центре обработки данных. Еще одна функция Cassandra — политика разбиения. Политика разделения решает, где и на каком узле разместить ключ. Это также может быть случайным или упорядоченным. При использовании обоих типов политик секционирования Cassandra может найти баланс между балансировкой нагрузки и оптимизацией производительности запросов.
• Последовательность. Такие функции, как репликация, усложняют согласованность. Это связано с тем, что все узлы должны быть обновлены в любой момент времени с последними значениями или в момент запуска операции чтения. В конце концов, однако, Cassandra пытается поддерживать баланс между действиями репликации и действиями чтения/записи, предоставляя эту возможность настройки разработчику.
• Чтение/запись действий. Клиент отправляет запрос на один узел Cassandra. Узел, в соответствии с политикой репликации, сохраняет данные в кластер. Каждый узел сначала выполняет изменение данных в журнале фиксации, а затем обновляет структуру таблицы с изменением, оба выполняются синхронно. Операция чтения также очень похожа, запрос на чтение отправляется на один узел, и именно этот узел определяет, какой узел содержит данные в соответствии с политикой разделения/размещения.

MongoDB

MongoDB — это документно-ориентированная база данных без схем, написанная на C++. База данных основана на хранилище документов, что означает, что она хранит значения (называемые документами) в виде закодированных данных.

Выбор закодированного формата в MongoDB — JSON. Это мощно, потому что даже если данные вложены в документы JSON, они все равно будут доступны для запросов и индексирования .

В следующих подразделах описываются некоторые ключевые функции, доступные в MongoDB.

Осколки

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

Язык запросов Монго

Как обсуждалось ранее, MongoDB использует RESTful API. Для извлечения определенных документов из коллекции БД создается документ запроса, содержащий поля, которым должны соответствовать нужные документы.

Действия

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

Подобно Cassandra, сегмент в MongoDB имеет схему репликации данных, которая создает набор реплик каждого сегмента, который содержит точно такие же данные. В MongoDB есть два типа схем реплик: репликация Master-Slave и репликация Replica-Set. Replica-Set обеспечивает большую автоматизацию и лучшую обработку сбоев, в то время как Master-Slave иногда требует вмешательства администратора. Независимо от схемы репликации, в любой момент времени в наборе реплик только один шард действует как первичный шард, все остальные сегменты реплики являются вторичными шардами. Все операции записи и чтения выполняются в основном сегменте, а затем равномерно распределяются (при необходимости) на другие вторичные сегменты в наборе.

На приведенном ниже рисунке мы видим описанную выше архитектуру MongoDB, на которой серверы-маршрутизаторы показаны зеленым, серверы конфигурации — синим, а осколки, содержащие узлы MongoDB.

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

Структуры индексирования для баз данных NoSQL

Индексирование — это процесс связывания ключа с расположением соответствующей записи данных в СУБД. В базах данных NoSQL используется множество индексирующих структур данных. В следующих разделах кратко обсуждаются некоторые из наиболее распространенных методов; а именно индексирование B-Tree, индексирование T-Tree и индексирование O2-Tree.

Индексация B-дерева

B-Tree — одна из наиболее распространенных структур индексов в СУБД.

В B-деревьях внутренние узлы могут иметь переменное количество дочерних узлов в пределах некоторого предопределенного диапазона.

Одним из основных отличий от других древовидных структур, таких как AVL, является то, что B-Tree позволяет узлам иметь переменное количество дочерних узлов, что означает меньшую балансировку дерева, но больше неиспользуемого пространства.

B+-дерево — один из самых популярных вариантов B-дерева. B+-Tree — это усовершенствование B-Tree, которое требует, чтобы все ключи находились в листьях.

Индексирование T-дерева

Структура данных T-Trees была разработана путем объединения функций AVL-Trees и B-Trees.

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

Структура T-Tree очень похожа на AVL-Tree и B-Tree.

Каждый узел хранит более одного кортежа {ключ-значение, указатель}. Кроме того, бинарный поиск используется в сочетании с узлами с несколькими кортежами для улучшения хранения и производительности.

T-дерево имеет три типа узлов: T-узел с правым и левым дочерними элементами, листовой узел без дочерних элементов и полулистовой узел только с одним дочерним элементом.

Считается, что T-деревья имеют лучшую общую производительность, чем AVL-деревья.

Индексация O2-дерева

O2-дерево в основном является улучшением по сравнению с красно-черными деревьями, формой дерева двоичного поиска, в котором конечные узлы содержат кортежи {значение ключа, указатель}.

O2-Tree был предложен для повышения производительности существующих методов индексирования. O2-дерево порядка m (m ≥ 2), где m — минимальная степень дерева, удовлетворяет следующим свойствам:

• Каждый узел либо красный, либо черный. Корень черный.
• Каждый листовой узел окрашен в черный цвет и состоит из блока или страницы, содержащей пары «ключ-значение, запись-указатель».
• Если узел красный, то оба его потомка черные.
• Для каждого внутреннего узла все простые пути от узла к дочерним листовым узлам содержат одинаковое количество черных узлов. Каждый внутренний узел содержит одно значение ключа.
• Листовые узлы — это блоки, содержащие от ⌈m/2⌉ до m пар «ключ-значение, запись-указатель».
• Если дерево имеет один узел, то это должен быть лист, являющийся корнем дерева, и он может иметь от 1 до m ключевых элементов данных.
• Листовые узлы имеют двойную связь в прямом и обратном направлениях.

Здесь мы видим прямое сравнение производительности между O2-Tree, T-Tree, B+-Tree, AVL-Tree и Red-Black Tree:

Порядок используемых T-деревьев, B+-деревьев и O2-деревьев был m = 512.

Время записывается для операций поиска, вставки и удаления с коэффициентами обновления, варьирующимися от 0% до 100% для индекса из 50 миллионов записей, при этом операции приводят к добавлению в индекс еще 50 миллионов записей.

Понятно, что при коэффициенте обновления 0-10% B-Tree и T-Tree работают лучше, чем O2-Tree. Однако с увеличением коэффициента обновления индекс O2-Tree работает значительно лучше, чем большинство других структур данных, причем больше всего страдают структуры B-Tree и Red-Black Tree.

Дело в NoSQL?

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

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

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

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

Не все системы баз данных NoSQL работают лучше, чем реляционные базы данных.

MongoDB и Cassandra имеют аналогичную, а в большинстве случаев лучшую производительность, чем реляционные базы данных, в операциях записи и удаления.

Прямой зависимости между типом хранилища и производительностью СУБД NoSQL нет. Реализации NoSQL претерпевают изменения, поэтому производительность может различаться.

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

Хотя я не могу дать окончательный вердикт о производительности, вот несколько моментов, о которых следует помнить:

• Традиционное индексирование B-Tree и T-Tree обычно используется в традиционных базах данных.
• В одном исследовании предлагались улучшения и усовершенствования путем объединения характеристик нескольких структур индексации для создания O2-Tree.
• O2-Tree превзошла другие структуры в большинстве тестов, особенно с огромными наборами данных и высоким коэффициентом обновления.
• Структура B-Tree показала наихудшую производительность среди всех структур индексации, описанных в этой статье.

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

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

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