Главная » Хабрахабр » DevConf: перспективные базы данных для highload

DevConf: перспективные базы данных для highload

DevConf 2018 уже на следующей неделе! В прошлом году Юрий Насретдинов провел интересный обзор перспективных систем хранения данных для highload. Видео с докладом доступно на странице доклада. А для хабра-читателей предлагаю краткий пересказ.

В начале расскажу как нужно подходить к выбору технологии для highload-проекта.

  • В первую очередь, должно быть понимание как оно работает. Не только сильные, но и слабые стороны.
  • Знание как это мониторить и бэкапить. Без хороших инструментов для этого, эту технологию рано использовать в продакшене.
  • Рано или поздно системы «падают»(это нормальная, штатная ситуация) и нужно знать что делать в этом случае.

Приведу примеры успешных технологий.

MySQL и MongoDB начинали с очень простых, дубовых, решений, которые просто работают и имеют понятные недостатки.

Tarantool

Для какого юзкейса был создан Tarantool? Представьте, что у вас социальная сеть и данные пользователей размазаны по сотне mysql-серверов. При этом, юзеры расшардены по user id. Пользователь вбивает свой email и хочет авторизоваться.

Но, у людей есть еще и номер телефона, по которому он тоже хочет авторизоваться. Очевидный выход — шардить юзеров по email. Но на тот момент таких баз данных не было, как один из вариантов на тот момент — складывать это все в мемкеш. Соответственно, второй очевидный выход — некая база данных, быстрая, которая содержит в себе соответствия email => userId, телефон => userId и желательно, чтобы такая база была персистентная. С мемкешом проблем довольно много, но по крайней мере он выдерживает большую нагрузку на чтение и на запись. Но допустим, операция добавления нового поля для поиска userId будет весьма непростой.

Хранит все данные в памяти. Итак, Tarantool. По заверениям разработчиков, выдерживает 1 миллион запросов в секунду на процессорное ядро. И, одновременно, на диске. Константин Осипов, один из разработчиков Tarantool, раньше разрабатывал MySQL. Разрабатывается в mail.ru.

Множество клиентов запрашивают сервер Tarantool. Процесс обработки запросов в Tarantool имеет конвейерную архитектуру. Потом он через некоторые промежутки времени передает их на выполнение. Все эти запросы сохраняются в очередь, в I/O thread. Таким образом блокировка execution thread идет на довольно маленькое время.

Если кто использует redis с персистентностью, то наверняка замечает, что редис «залипает» на довольно длительный промежуток времени в тот момент, когда идет процесс создания форка. Отдельно стоит упомянуть персистентность. До версии 1. У Tarantool другая модель. 7 он часть памяти держал в shared регионе и при форке она не копируется. 6. С версии 1. И пока форкнутый child пишется на диск, parent знает, что этот кусок памяти трогать нельзя. 7 они вообще отказались от форка. 6. User-space memory address translation. Они поддерживают, можно сказать, механизм виртуальной памяти в user-space. Вместо создания форк-процесса создается thread, который пробегается по снэпшоту памяти в user-space и записывает на диск консистентный снэпшот.
Для каких ситуаций подходит Tarantool:

  • У вас много читающих/пишущих клиентов.
  • Много мелкого чтения/записи.
  • Когда у вас есть необходимость в некоем центральном хранилище и рабочий набор влезает в память. Tarantool пока не поддерживает шардинг.
  • Желание писать хранимые процедуры. Tarantool поддерживает их на Lua.
  • Авторизация, сессии, счетчики.

Когда не стоит его использовать:

  • Если нужны: автоматический шардинг и failover, Raft/Paxos, длинные транзакции.
  • Мало клиентов и требование минимальной latency. Из-за конвейерной архитектуры latency будет больше, чем минимально возможная.
  • Рабочий набор не влезает в память. Костя Осипов только что рассказывал о новом движке Винил для Tarantool, но я рекомендую вам его проверить сначала.
  • Ну и мое личное мнение: Tarantool не подходит для задач аналитики. Не смотря на то, что данные он держит все в памяти, но держит он их не так, как надо для этих задач.

ClickHouse

Создан Яндексом как раз для аналитики. Для систем подобных Яндекс.Аналитике нужны были базы данных:

  • Эффективные и линейно-масштабируемые.
  • Аналитика в реалтайме.
  • Бесплатная и open-source.

На тот момент продукта, удовлетворяющим всем трем критериям, не было. Возможные решения:

  • MySQL(MyISAM) — быстрая запись, медленное чтение
  • Vertica, Exasol — платные
  • Hadoop — на запись работает, но чтение не realtime.

Яндекс сначала использовал MySQL. но потом написал ClickHouse — распределенную СУБД для аналитики, которая хранит данные по колонкам, оптимизирована для HDD(SSD — довольно дорогие) и исключительно быстрая(может сканировать до миллиарда записей в секунду). Она уже протестирована в продакшене Яндекса. ClickHouse поддерживает только вставку и запрос данных. Нет удаления и редактирования.

В каждой партиции данные упорядочены по возрастанию первичного ключа. Данные хранятся по месячным партициям. «Первичный ключ» в данном случае не очень правильно, поскольку не гарантируется его уникальность.

Это позволяет с малым количеством операций с диском выполнять запросы с range первичного ключа. Чтобы можно было быстрее искать по первичному ключу в ClickHouse используются файлы «засечек», где раз в какое-то количество записей делаются засечки со значением первичного ключа и где он находится.

Данные пишутся во временную партицию, отсортированно. Insert происходит так. После чего, фоновым процессом, когда запись на какое-то время останавливается, происходит merge эти партиций.
Возможности ClickHouse:

  • SQL, ограниченные JOIN.
  • Репликация и работа в кластере. Поддерживается, но надо постараться.
  • 17(наверняка уже больше) алгоритмов выполнения Group by.
  • Materialized views, global JOIN's.
  • Выборки с сэмплированием. Когда можно оптимально прочитать только часть данных. Например, только для определенного юзера в Яндекс.Аналитике.

Сценарии использования:

  • Задачи realtime-аналитики.
  • Time-series — github.com/yandex/graphouse
  • Хранение сырых данных, которых ClickHouse умеет очень быстро агрегировать. Показы, клики, логи, etc.

Когда не использовать:

  • OLTP-задачи(нет транзакций)
  • Работа с деньгами(нет транзакций)
  • Хранение агрегированных данных(нет смысла)
  • Map/Reduce задачи.(многие из них прекрасно решаются с помощью SQL)
  • Полнотекстовый поиск(не предназначен)

CockroachDB

Есть база пользователей, размазанная по серверам. Предпосылки создания такие же как и у Tarantool. Но если Tarantool в нашем примере выступает в виде такого высокоуровневого индекса к шардам базы данных, то CockroachDB предлагает хранить все у себя.
Возможные решения до CockroachDB: И нужно искать, например по email или телефону.

Google Cloud Spanner
Authorizer + ручной шардинг(как мы уже рассматривали с Tarantool)
MongoDB, Cassandra — не поддерживают распределенные уникальные индексы.

Все хотят SQL. Изначально CockroachDB создавался как распределенный Key-Value Storage, но текущие реалии подсказывают, что новая Key-Value база данных мало кому нужна. Создан авторами Google Spanner. Он поддерживает SQL, JOIN, транзакции, ACID, уникальные индексы, автоматический шардинг. Почти с первого раза прошел тестирование Jepsen. Написан на Go. И уже используется в продакшене в Baidu.

Вручную это можно организовать довольно просто. Как же реляционная модель ложится на Key-Value хранилище? В CockroachDB это все немного сложнее. Я приведу сильно упрощенный вариант. Ключи получаются довольно простые — имя таблицы/значение первичного ключа/имя поля.

Еще один ключ с именем индекса. Вторичные индексы тоже довольно понятные. В случае неуникального индекса — вместе со значением первичного ключа.

Глобальный отсортированный Key-Value map разбит на регионы, которые база старается поддерживать примерно в 64 Мб. Данные хранятся довольно тривиальным способом, но мне он кажется очень правильным. вся запись(вероятно и чтение тоже) идет в него. Каждый из этих регионов отреплицирован на несколько узлов и один из этих узлов для региона является Raft-лидером, т.е. Raft позволяет достаточно быстро выбрать нового лидера для каждого региона. Теперь представим, что какая-то нода выпала. Таким образом, и запись и чтение будут доступны.

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

Сейчас же пока рано, поскольку 1. В будущем CockroachDB вполне может быть использован как главная база данных большого проекта. 0 релиз вышел совсем недавно.

Когда не использовать:

Если в проекте требуется низкая latency или высокий Queries per second — не стоит. Как вы могли заметить из описания алгоритма распределенных транзакций CockroachDB процесс этот не быстрый. Хотя для распределенной базы данных это довольно важный фактор. Запись также не самая быстрая.
Если вам не нужна строгая консистентность. Условно, если вам нужно послать сообщение от одного пользователя к другому, то записи о нем должны появиться и на сервере автора сообщения и на сервере того, кому это сообщение отправлено, и желательно это сделать атомарно.

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

Приходите делиться опытом. В этом году тоже довольно интересная секция Storage. Хабрачитателям скидка.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Всемирная организация здравоохранения официально признала существование игровой зависимости

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

[Перевод] Конструкция async/await в JavaScript: сильные стороны, подводные камни и особенности использования

Конструкция async/await появилась в стандарте ES7. Её можно считать замечательным улучшением в сфере асинхронного программирования на JavaScript. Она позволяет писать код, который выглядит как синхронный, но используется для решения асинхронных задач и не блокирует главный поток. Несмотря на то, что ...