БАЗЫ ДАННЫХ И ЗНАНИЙ
УДК 681.32
СИСТЕМЫ УПРАВЛЕНИЯ ДАННЫМИ КАТЕГОРИИ NoSQL
© 2014 г. С.Д. Кузнецов1, А.В. Посконин2
1 Институт системного программирования РАН 109004 Москва, ул. А. Солженицына, 25
2
119991 Москва, ГСП-1, Ленинские горы, МГУ, д. 1, стр. 52 E-mail: kuzloc@ispras.ru, aposk@yandex.ru Поступила в редакцию 28.05.2014
В последнее десятилетие активно стали появляться и развиваться системы управления данными, получившие собирательное название "NoSQL". Основными особенностями таких систем являются отказ от реляционной модели данных и языка SQL, отсутствие полноценной поддержки ACID-транзакций, использование распределённой архитектуры (хотя существуют и нераспределённые NoSQL-системы). Благодаря этому в ряде задач удаётся добиться производительности, превосходящей производительность традиционных SQL-ориентированных СУБД, а также обеспечить хорошую масштабируемость при возрастающих нагрузках и огромных объемах данных, что является крайне важным, в частности, для \¥еЬ-приложений. К сожалению, отсутствие транзакционной семантики накладывает некоторые ограничения на класс задач, которые можно эффективно решать с помощью NoSQL-систем, а выбор конкретной системы сильно зависит от решаемой задачи. В данной работе предлагается обзор основных классов систем управления данными, которые наиболее часто относят к категории NoSQL, рассматриваются примеры конкретных систем и задач, которые могут быть решены с их помощью.
1. ВВЕДЕНИЕ
Термин "NoSQL" был впервые применен в 1998 году Карло Строцци (Carlo Strozzi) в качестве названия для его небольшой реляционной СУБД, которая не использовала язык SQL для манипулирования данными [1]. С 2009 года термин "NoSQL" стал использоваться уже для обозначения растущего числа распределенных систем управления данными, которые отказывались от поддержки ACID-транзакций (Atomicity, Consistency, Isolation, Durability -Атомарность, Согласованность, Изолированность, Постоянство хранения) - одного из ключевых принципов работы с реляционными базами данных [2]. По мнению Строцци, современные системы категории NoSQL точнее было бы называть нереляционными ("NoREL") [1]. В настоящее время термин "NoSQL" обычно расшифровывается как "Not Only SQL", то есть "Не Только SQL" [3].
Главной предпосылкой к появлению систем, относимых к категории NoSQL, послужила растущая потребность в горизонтальной масштабируемости приложений, то есть в возможности наращивать производительность путём добавления новых вычислительных узлов к уже работающим. Таким образом, большинство \oSQI.-ene гс.м изначально проектировались и создавались для работы в распределенной среде - кластере или облаке, где применение традиционных SQL-opиeнтиpoвaнныx систем связано с определёнными трудностями (см., например, [4], [5]). Основной причиной отказа от поддержки транзакционной семантики послужила сложность эффективной реализации транзакций в распределённой среде: в общем случае приходится использовать двухфазный протокол фиксации транзакций, который требует пересылки большого количества сообщений по сети (см., например, [6]). Хотя
NoSQL-системы обычно не поддерживают ACID-транзакции в полном объеме, в ряде случаев поддерживаются, например, атомарные операции для чтения и модификации, оптимистические блокировки и другие инструменты, помогающие упростить разработку приложений в условиях параллельного доступа к данным.
В данной работе будут рассматриваться системы, относимые в публикациях к категории NoSQL. К сожалению, рассмотреть все существующие NoSQL-решения не представляется возможным (на момент написания работы список [3] насчитывал порядка 150 систем), а многие системы достаточно сложны и обладают богатой функциональностью, поэтому в соответствующих разделах будут приведены только ключевые особенности конкретных решений, такие как модель данных, возможности масштабирования и т.д. Кроме того, NoSQL-движение является достаточно молодым, поэтому многие проекты находятся в стадии активной разработки и претерпевают значительные изменения от версии к версии. Наиболее актуальную и полную информацию о рассматриваемых системах читатель может получить, используя ссылки, приведённые в тексте.
2. ОСОБЕННОСТИ NoSQL-CHCTEM
Как уже было отмечено, большинство NoSQL-систем являются распределенными. Распределённая архитектура позволяет достичь не только горизонтальной масштабируемости (в идеале -линейного роста производительности при добавлении новых узлов), но и увеличить надежность системы с помощью поддержания нескольких копий данных. В распределённых системах управления данными используются два основных приёма (практически всегда применяемых совместно).
1. Разделение данных (шардинг, sharding) -подход, при котором каждый узел системы содержит свою часть данных и выполняет операции над ними. Этот метод является основным средством обеспечения горизонтальной масштабируемости, однако теперь операции над несколькими объектами могут вовлечь в работу несколько узлов, что требует активной передачи данных по
сети. Кроме того, при увеличении числа узлов, хранящих данные, увеличивается вероятность сбоев, что требует наличия избыточности - применения репликации (см. далее). Шардинг также порождает такие задачи, как распределение данных по узлам, балансировка нагрузки, оптимизация сетевых взаимодействий и т.д.
2. Репликация (replication) - подход, при котором одни и те же данные хранятся на нескольких узлах в сети. Этот метод помогает повысить надежность системы и справляться как со сбоями отдельных узлов, так и с потерей целого кластера. Кроме того, репликация позволяет масштабировать операции чтения (несколько реже - записи). Серьезной задачей является поддержка согласованного состояния копий данных (реплик): при синхронном обновлении реплик увеличивается время ответа системы, а при асинхронном - возникает промежуток времени, когда реплики находятся в несогласованном состоянии.
Существуют две основные схемы репликации (поддерживающие как синхронные, так и асинхронные варианты).
1. Ведущий-ведомый (master-slave) - при такой схеме репликации операции модификации данных обрабатывает только ведущий узел (master), а сделанные изменения синхронно или асинхронно передаются на ведомого (slave). Чтения могут осуществляться как с ведущего узла (гарантированно содержит последнюю версию данных), так и с ведомого (данные могут быть несколько устаревшими при асинхронной репликации и "отставать" от ведущего).
2. Ведущий-ведущий (master-master, multimaster) - при этой схеме все узлы могут обрабатывать операции записи и передавать обновления остальным. В этом случае реализовать синхронную репликацию достаточно сложно, к тому же резко возрастают задержки, связанные с сетевыми взаимодействиями. При асинхронном обновлении возникает другая проблема -могут появиться конфликтующие версии
данных, которые требуют наличия механизма для определения и разрешения конфликтов (автоматически или на уровне приложения).
2.1. Модели согласованности
Применение репликации в распределённой системе порождает задачу поддержания идентичного состояния копий данных на разных узлах (и, соответственно, видимых разными клиентами). Для обозначения гарантий согласованности данных, которые предоставляются системой, используют термин "модель согласованности" (consistencv model). Следует отметить, что слово "согласованность" в этом контексте отличается от свойства согласованности из определения ACID-транзакций. Модель согласованности определяет физическую согласованность состояния данных на разных узлах системы, в то время как в случае ACID имеется в виду логическая согласованность (в рамках ограничений целостности, определённых для базы данных). Ниже приводятся примеры моделей, часто применяемых в NoSQL-системах (см., например, [7]):
Согласованность в "конечном счёте" (eventual consistencv) гарантирует, что при отсутствии новых обновлений в течение некоторого времени все копии данных (реплики) станут согласованными.
Монотонные чтения (monotonie reads) являются усилением согласованности "в конечном счёте", гарантируя, что если какое-либо значение было прочитано клиентом, то последующие чтения никогда не вернут предыдущие значения.
Чтение своих записей (read your writes) также усиливает согласованность "в конечном счёте", давая гарантии того, что клиент всегда увидит данные, которые он до этого записал. Эта модель может также комбинироваться с монотонными чтениями.
Мгновенная согласованность (immediate consistency) означает, что как только операция модификации данных успешно завершена, все клиенты мгновенно увидят это изменение. Такую модель согласованности поддерживают, например, системы с синхронной репликацией.
Наиболее часто NoSQL-системы поддерживают согласованность "в конечном счёте" или
её вариации. При этом возникает период времени, в течение которого данные находятся в несогласованном состоянии, называемый "окном несогласованности" (inconsistency window). Его величина зависит (при отсутствии сбоев) от скорости распространения обновлений, загруженности системы и количества узлов, содержащих реплики данных. Приложения, использующие системы управления данными, допускающие несогласованность, должны уметь справляться с появлением несколько "устаревших" данных (в [8] проверяется, насколько часто это может происходить на практике при использовании различных облачных NoSQL-систем). Кроме того, при одновременных обновлениях реплик данных возникают конфликтующие версии. Для обнаружения конфликтов применяются такие подходы, как временные метки и векторные часы (см., например, [9]). Для разрешения конфликтов существуют различные стратегии, но обычно наиболее точное решение о том, какую версию выбрать, может сделать только само приложение (о различных стратегиях разрешения конфликтов см., например, [10]).
В некоторых системах уровень поддержки согласованности можно варьировать, используя различные конфигурации, настройки и/или операции. Рассмотрим, как этого можно добиться на практике с помощью кворума. Пусть данные реплицируются по N-узлам; обозначим через R - число узлов, к котор
Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.