Shashank Tiwari - Scalable SQL and NoSQL Data Stores

В этой статье рассматривается ряд SQL и так называемых "NoSQL" хранилищ данных которые предназначены для масштабирования простых OLTP-приложений распределенных на многих серверах. Первоначально мотивированные приложениями Web 2.0 , эти системы были спроектированы с учетом возможность масштабирования до тысяч или миллионов пользовательских запросов на чтение или обновление данных, чем отличались от традиционных СУБД или хранилищ данных. Отличительной чертой новых систем является модель данных, согласованность механизмов, методы хранения данных, долговечность, доступность, поддержка запросов и другие. При использовании подобных систем обычно приходится жертвовать некоторыми характеристиками, такими как согласованность транзакций всей базы данных, с целью достижения других, например высокой доступность и масштабируемости.

Примечание: Ссылки на литературу для системы не приведены, но URL-адреса для получения дополнительной информации можно найти в таблице ссылок в конце этой статьи.

Предостережение: Заявления в настоящем документе, основаны на источниках, и документации, которые могут быть ненадежными и описанные системы являются "изменчивыми", поэтому некоторые заявления могут быть неточными. Прежде чем ссылаться на приведенную информацию, проверьте ее актуальность в других источниках. Тем не менее, мы надеемся, что это исследование является всеобъемлющим и полезным! Если вы нашли неточности в статье присылайте их на веб сайт автора cattell.net/datastores.

Публикуемые сведения: автор является техническим консультантом в компании Schooner Technologies и проводит консультации по масштабированию баз данных.

Обзор

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

В этой статье выделено 6 основных особенностей NoSQL систем:

1. возможность горизонтального масштабирования "простых операций" на большое количество серверов

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

3.простой интерфейс уровня вызовов или протокол (в отличие от SQL ограничений)

4. боле слабая согласованность модели, чем ACID транзакции в большинстве реляционных (SQL) базах данных

5. эффективное использование распределенных индексов и оперативной памяти для хранения данных

6. возможность динамически добавлять новые атрибуты к записям данных.

Имеются и другие отличия в системах и в этой статье они будут противопоставлены. Системы ранжируются по функциональности от использования простейшего распределенного хеширования, такого как memcached в популярных открытых кэш источниках, до использования высоко масштабируемых секционированных таблиц, а таких как BigTable поддерживаемых компанией Google[1]. В самом деле, BigTable, Memcached и Amazon's Dynamo [2] предоставили "доказательство концепции", которые вдохновили создателей многих из хранилищ данных, описываемых здесь:

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

• Dynamo первыми предложили идею согласованности в конечном счете, как способа достижения более высокой доступности и масштабируемости: извлеченные данные не являются гарантированно актуальными но обновления будут гарантированно распространены на все узлы в конечном счете.

• BigTable продемонстрировали, что постоянное хранилище записи может быть расширено до тысяч узлов, подвиг, к которому большинство других систем только стремятся.

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

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

BASE = Basically Available, Soft state (в основе доступность, мягкая структура), согласованность в конечном счете

ACID = Atomicity, Consistency, Isolation, and Durability (атомарность, согласованность, изолированность и долговечность).

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

Тем не менее, эти системы отличаются в том, насколько они уступают друг другу. Например, большинство систем называют себя "в конечном счете согласованными", что означает, что обновления в конечном счете распространяются на все узлы, но многие из них предоставляют в механизмах определенную степень последовательности, например многоверсионное управление (MVCC).

Границы данной статьи

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

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

Терминология модели данных

В отличие от реляционных (SQL) СУБД терминология, используемая в NoSQL хранилищах данных, часто является непоследовательной. Целью данной статьи является последовательное сравнение моделей данных и функциональности. Все описанные системы предоставляют возможность хранить скалярные значения, как числа и строки, а также данные вида BLOB. Некоторые из них также предоставляют возможность хранить более сложные вложенные или ссылочные значения. Все системы хранилищ данных используют пары вида атрибут-значение, но используемая структура является различной, в частности:

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

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

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

• "Объект" является аналогом объекта в языках программирования, но без процедурных методов. Значениями могут быть ссылки или вложенные объекты.

Категории хранилищ данных

В этой статье хранилища данных сгруппированы в соответствии с их моделью данных:

хранилище ключ-значение: это система хранения значений и ключей для их поиска, основывается на программно-определенном ключе.
Документо-ориентированное хранилище: это система хранения документов, которые только определены. Документы индексируются и предоставляется простой механизм запросов.
Хранилище с расширяемыми записями: система хранения расширяемых записей, разделена вертикально и горизонтально на узлы. В некоторых источника данное хранилище называется «Хранилище широких столбцов»
Реляционная база данных: система хранения(поддерживающая индексы и запросы) кортежей. Новые возможности реляционной СУБД по горизонтальному масштабированию будут рассмотрены в данной статье.

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

Хранилища Ключ – Значение

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

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

Проект Волдеморт

Проект Волдеморт является передовым хранилищем типа ключ-значение, написанным на Java. Это открытый исходный код, с существенными LinkedIn взносами. Волдеморт предоставляет многоверсионную систему управления (MVCC) для обновлений. Обновление репликации происходит асинхронно, поэтому согласованность данных не гарантируется. Тем не менее, гарантируется уникальное представление при чтении большинства реплик. Волдеморт поддерживает оптимистическую блокировку для последовательной записи нескольких обновлений: если обновления конфликтует с любым другим процессом, они могут быть отменены. Векторные часы, используемые в Dynamo [3], обеспечивают порядок версий. Вы также можете указать какую версию вы хотите обновить, используя операцию вставки и удаления.

Riak

Riak написан на Erlang. Он является проектом с открытым кодом, написанным Басе в середине 2009 года. Басе двояко описывает Riak как хранилище "ключ-значение " и "документо ориентированное хранилище". В данной статье он классифицируется как хранилище ключ-значение, потому что не хватает важных особенностей для отнесения его к документо ориентированному хранилищу, но он (и Волдеморт) имеет больше возможностей, чем другие хранилища типа ключ-значение:

• Riak объекты могут быть выбраны и сохранены в формате JSON, и, следовательно, могут иметь несколько полей (например, документов). Объекты могут быть сгруппированы в блоки, как и коллекции, поддерживаемые документо ориентированными хранилищами, с разрешенными / необходимые полями.

• Riak не поддерживает индексы на любых полях, кроме первичного ключа. Единственное, что вы можете сделать с не первичным полем выбирать и сохранять его как часть объекта JSON. В Riak отсутствует механизм запроса документо ориентированного хранилища, единственное что можно сделать при поиске, это использовать первичный ключ.

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

Redis

Redis это хранилище типа ключ-значение изначально разрабатывалось одним человеком, но теперь проект имеет нескольких авторов, проект с открытым исходным кодом. Он написана на C.

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

Выводы

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

Scalaris Memcached - расширенные системы и используют синхронную репликацию, асинхронная используется в остальных. Scalaris и Кабинет Токио наследуют транзакции, в то время как другие нет.

Волдеморт и Riak используют системы многоверсионного управления (MVCC), другие используют замыкания. Membrain и Membase строятся на популярных memcached системах, с добавлением отказоустойчивости, репликации и других функций. Обратная совместимость с memcached дает этим системам преимущество.

Масштабирование SQL и NoSql хранилищ данных