Riak — простая, предсказуемая и масштабируемая БД. Преимущества и недостатки.

Видео

Презентация

Анонс

Как выглядит стандартный путь rdbms по мере ее роста? Примерно так:

  1. SQL-запросы с минимальным включением мозга — просто делающие то, что надо.
  2. Добавление индексов и лимитов в особо злостные места.
  3. Внешнее кэширование, асинхронные очереди, реплика, иногда самописные демоны на си/node.js/etc.
  4. SSD/RAID, десятки и сотни гигабайтов памяти, чтоб держать dirty page buffer побольше.
  5. Предагрегирование части (или всех) запросов типа GROUP BY/COUNT, т.к. делать их “на лету” по большой бд - слишком дорого.
  6. Функциональный шардинг, опционально partioning больших таблиц.
  7. Шардинг по ключу (юзеру/документу).

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

  • Нет джойнов,
  • Нет транзакций (т.к. их довольно сложно сделать меж шардами),
  • Нет триггеров (опять же вся логика меж кластерного взаимодействия в коде),
  • К таблицам нельзя сделать сколько-нибудь сложный запрос (не дай бог сделать GROUP BY или SELECT не по индексу или с большим количеством random-seek`ов),
  • Сложно изменять схему, добавлять индексы.

Ну и где PROFIT ? Стоило ли проходить весь этот путь?


Фактически по мере развития бд мы превратили ее в не-очень-то подходящее key-value с набором костылей, чтоб это все работало и не сильно тормозило, да и еще, скорее-всего, с единой точкой отказа в виде мастер-сервера. Может быть стойло попробовать пойти по другому пути? Который бы сразу вел нас по дороге высокой доступности, линейной масштабируемости и отсутствия единых точек отказа?

Есть альтернативный путь — использование Riak как средства хранения данных, разработанного с фокусом на высокой доступности и устойчивости, а так же операционной простоте:

  • Вместо того, чтобы писать хитрые схемы миграции данных и ребалансировки, вы просто делаете riak-admin join riak@node.
  • Вместо того чтобы разбираться с распределенными транзакциями и миграциями данных вы просто работаете с key-value хранилищем (которое правда умеет учитывать конфликты записи).

Но это не волшебная таблетка:

  • Если в RDBMS индекс и count(*) были всего лишь парой строк sql`я, то реализация того же самого в распределенной системе уже не такая простая задача.
  • Атомарность операций — практически нонсенс в распределенной системе. Запись может потеряться, а потом “найтись”, индекс может рассинхронизироваться с данными.
  • И другие нюансы ...

Цель этого доклада: рассказать о том, как это сделано в Riak`e, почему оно сделано так, пояснить, что это все не бесплатно и какую придется пройти learning curve. Ну и понять, какие задачи можно решать с его помощью, что можно, а что не желательно делать и какие подводные камни могут встретится на этой дороге.

Комментарии

{{comment.AuthorInfo}}
{{ comment.DateCreated | date: 'dd.MM.yyyy' }}

Партнеры конференции

Заметили ошибку?