Анти-RDBMS: Список распределенных хранилищ ключ-значение

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

Вы страдаете манией Облачной обработки данных (Cloud-computing).

Вам нужно оправдание, чтобы держать Erlang постоянно работающим.

Вы слышали, что CouchDB - это клево.

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

Ваши данных хранятся и выбираются по первичному ключу, без сложных join'ов.

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

Какие бы не были у вас причины, есть множество вариантов выбора. В Last.fm мы делали множество пакетных вычислений внутри Hadoop, затем клали дамп на другую машину, где все индексировалось и через HTTP и Thrift отображалось как внутренний сервис (такой как ‘most popular songs in London, UK this week’ и др). В настоящее время мы используем самодельный формат индексов для больших файлов который охватывает множество ключей (spanning many keys), приблизительно похожий на Haystack, обсуждавшийся в данной статье в отношении фото-хранилища Facebook. Он работает, но вместо разработки нашей собственной системы репликации и сегментирования поверх нее, мы предпочитаем найти возможную замену этому при помощи распределенной отказоустойчивой системы хранения ключ-значение по причинам 4, 5 и 6 описанным выше.

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

Глоссарий и дополнительные материалы

Distributed Hash Table (DHT) и такие алгоритмы как Chord и Kadmelia

Amazon’s Dynamo Paper, и статья ReadWriteWeb про Dynamo, в которой объясняется почему такие системы бесценны

Amazon’s SimpleDB Service, и некоторые комментарии

Google’s BigTable

The Paxos Algorithm - прочтите эту статью для того, чтобы понять в полной мере, что реализация алгоритма Paxos это не, чем бы вы хотели заниматься с похмелья в субботу утром.

Краткий список

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

Почему пять из них нам не подходят

В действительности я ищу реплицируемое распределенное хранилище ключи-значения с минимальным временем отклика. Оно должно хорошо масштабироваться при добавлении хостов, и не должно требовать сложной настройки или обслуживания - оно должно просто работать. API должно быть таким же, как для простой хеш-таблицы: set(key, val), get(key), delete(key). Это позволит избежать проблем с управлением sharded / настройкой репликации баз данных, и будем надеяться, что оно способно эффективно управлять данными по первичному ключу.

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

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

2) Hypertable обеспечивает набор возможностей, похожий на Hbase (к тому же, оба они были сделаны по мотивам Google BigTable). Недавно [команда] Hypertable объявила о своем новом спонсоре, им стал Baidu - крупнейший китайский поисковый движок. В любом случае Hypertable не обеспечивает малой задержки отклика.

3) Cassandra выглядела многообещающе в прошлом году, когда Facebook выложил ее исходники. Они использовали Cassandra для поиска во входящих почтовых ящиках. Cassandra напоминает Bigtable, но использует DHT - так что не нуждается в центральном сервере (один из разработчиков Cassandra до этого работал в Amazon над проектом Dynamo). К сожалению, ее дальнейшее будущее покрыто мраком с момента выхода, потому что Facebook'у никогда не был интересен этот проект в качестве open source. Из того, что я могу сказать, сейчас существует не так много документации и коммьюнити вокруг этого проекта.

4) CouchDB является интересным - это "распределенное, отказоустойчивое и документо-ориентированная база данных без фиксированной схемы (schema-free), доступная через "протоколы без состояние" типа HTTP / JSON API". Данные хранятся в "документах", которые являются отображением ключей на значения, с использованием типов данных из JSON. Прочите _CouchDB Technical Overview_ если вам интересна внутренняя работа основной (trendiest) документо-ориентированной база данных для веба. Статья _Rules of Database App Aging_ некоторым образом объясняет почему документо-ориентированные базы данных имеют смысл. CouchDB может сделать полное индексирование текста ваших документов, и обеспечит быстрый просмотр через JavaScript. Я могу представить себе использование CouchDB для хранения множества данных пользователя: имени, возраста, пола, адреса, IM-ника и множества других полей, многие из которых могут быть пустыми (null), и любой сайт добавляет или изменяет доступные поля. В подобных ситуациях добавление и изменение колонок в базе данных становится быстро выходит из под контроля, так же приходится обновлять версию приложения чтобы она соответствовала базе. Хотя многие используют CouchDB в продакшене, в их FAQ указывает на то , что они могут внести обратно-несовместимые изменения в формат хранения и API до версии 1.0.

5) ThruDB это хранилище документов и система индексирования состоящая из четырех компонент: сервис хранения документов, сервис индексирования, очередь сообщений и прокси. В ней используется Thrift для коммуникаций, и имеется плагинная подсистема хранения, поддерживающая Amazon S3 в качестве опции. ThruDB спроектирована так, чтобы хорошо масштабироваться по горизонтали, и может быть лучшим выбором чем CouchDB при запуске на EC2. В последнее время я слышал гораздо больше про CouchDB чем про ThruDB, но на нее все же стоит взглянуть если вам нужна база данных для документов. Но она не подходит для наших нужд, по тем же причинам что и CouchDB.

Распределенное хранилище ключ-значение

Все остальные системы гораздо ближе к "простому" хранилищу ключи-значения с достаточно низкой задержкой, пригодной для обслуживания данных при построении динамических веб-страниц. Задержка будет зависеть от окружающей среды, а также о того, помещается или нет набор данных в памяти. Если условия выполняются, я ожидаю времени отклика меньше 10мс, а если нет, то все зависит от того, сколько денег вы потратили на жесткие диски (в оригинале spinning rust - вращающиеся металлолом :).

MemcacheDB это в основном только memcached, что экономит жесткие диски при использовании баз данных типа Berkeley. Хотя это может быть полезно в некоторых ситуациях, это не относится к репликации и сегментированию (sharding), так что по прежнему требуется много доработок чтобы сделать ее горизонтально-масштабируемой и устойчивой к аппаратным сбоям. Другие производные memcached такие как repcached предлагают некоторые способы решения, давая возможность целиком реплицировать memcahed-серверы (асинхронный master-slave режим), но отсутствие сегментирования мешает нормальному управлению.

Проект Voldemort впечатляет. Лучше всего читайте о нем на их сайта, где объясняется как это работает, и представлены хорошие диаграммы и описание того как последовательное (consistent) хеширование используется в его архитектуре. (Если последовательное хеширование вам понравилось - посмотрите на библиотеку libketama включающую также драйвер для Erlang). Проект Voldemort поддерживает репликацию и сегментирование данных, и выглядит хорошо спроектированным. При чтении документации обнадеживает то, что очень просто выгрузить и эмулировать различные компоненты для тестирования. Хотя добавление еще одной ноды к запущенному кластеру является не вполне тривиальной задачей, но исходя из их списков рассылок это вполне осуществимо. Похоже он будет отвечать всем требованиям если мы запустим его с Java-балансировщиком (см. диаграмму Physical Architecture Options у них) которые представит Thrift API так, что не-Java-клиенты смогут использовать его.

Scalaris является возможно самым человеческим из того, что вы могли собрать в Erlang. CouchDB, Ejabberd и RabbitMQ клевые, но в Scalaris упакована самая впечатляющая коллекция секси-технологий. Scalaris это хранилище ключей и значений, в нем используется модифицированный алгоритм Chord для формирования DHT, а ключи сохраняются в лексиграфическом порядке, так что возможно установить границы для запросов. Хотя я не видел чтобы об это говорилось прямо, но это открывает всевозможные интересные варианты пакетной обработки, например тот же map-reduced. Поверх DHT они используют улучшенный вариант Paxos, что гарантирует ACID-свойства, когда речь идет о множестве параллельных транзакций. Итак, это хранилище ключей и значений, гарантирующее ACID с возможностью распределенных транзакций на множестве ключей.

Oh, и для демонстрации того как вы можите масштабировать вебсервисы расположенные на таком типе систем, группа Scalaris реализовала их собственный вариант Wikipedia, загрузили туда данные и измерили производительность этой установки, чтобы доказать, что оно может выдавать больше транзакций в секунду на том же оборудовании по сравнению с классическим сочетанием PHP/MySQL которое использует Wikipedia. Ой, простите.

В настоящий момент Scalaris является резидентным и не сохраняет данных на диск. Это делает его совершенно бесполезным для запуска таких сервисов как Wikipedia - это выглядит так, как будто им трудно решить эту проблему, хотя сохранение на диск должно показаться прогулкой в парке, после того как они сделали собственную версию Chord и реализовали Paxos. Посмотрите презентацию Scalaris в конференции Erlang Exchange: _Scalaris presentation video_.

Оставшиеся проекты - Dynomite, Ringo и Kai в большей или меньшей степени пытаются быть похожи на Dynamo. Из этих трех, Ringo выглядит наиболее специализированным - он делает различие между маленькими (меньше 4Кб) и средними (<100Mb) кусками данных. Средние по размеру куски сохраняются в отдельных файлах, в то время как маленькие куски сохраняются в append-log файле, индекс которого считывается в память при запуске. Могу сказать, что Ringo может использоваться в связке с Erlang'овским map-reduced фреймворком от Nokia который называется Disco.

Я не смог найти большей информации о Kai, чем то что оно достаточно ново и связана с Японией. Вы можете выбрать Erlang или dets в качестве хранилища (память или диск, соотвественно), и оно использует протокол memcached так что подойдут уже существующие во многих языках клиентские библиотеки.

У Dynomite нет хорошей документации, но он представляется более перспективным чем Kai, к тому же находится в активной разработке. Он обладает плагинным backend'ом, включая механизм хранения CouchDB, так что 2Gb-ограничение на размер файлов не станет проблемой. Еще я слышал что Powerset использует Dynomite, и это обнадеживает.

Заключение

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

Я смотрю на Dynomite - в надежде найти больше информации о том, что Powerset делает с ним, и как оно реализует большое масштабирование.

Исходя из моих исследований до сих пор, Project-Voldemort выглядит наиболее подходящим для наших нужд. Я хотел бы больше услышать о том, как оно используется в LinkedIn, и как много нодов под ним запущено.

Что есть еще?

Есть несколько связанных проектов:

Hazelcast - Java DHT/clustering library

nmdb - сетевая база данных (dbm-style)

Open Chord - Java DHT

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

UPDATE: 1: memcachedb реплицируется, как и BerkeleyDB.