Доклад Юрия Насретдинова рассматривает перспективные СУБД для highload приложений, включая Tarantool, ClickHouse и CockroachDB. Он подчеркивает важность осмысленного выбора технологий, учитывающего архитектуру, мониторинг и возможные слабые места. Доклад завершает оценка применения каждой базы данных в различных сценариях, акцентируя внимание на их сильных и слабых сторонах.

1. Обзор перспективных
СУБД для highload
Юрий Насретдинов

2. План
• Обо мне
• Подход к выбору технологий
• Tarantool
• ClickHouse
• CockroachDB
• Заключение

3. Обо мне
• Зовут Юрий, в честь дедушки
• Написал свою СУБД на PHP
• Работал в Badoo ~5 лет в отделе «платформы»
• 10 лет опыта программирования на PHP
• Сейчас разрабатываю на Go

4. Зачем этот доклад?
• Индустрия IT быстро развивается
• Highload — тем более
• Через 10 лет ваши сегодняшние знания и
навыки безнадежно устареют

5. Подход к выбору технологий
1. Архитектуру
2. Не только сильные, но и слабые места
3. Как «это» мониторить и бэкапить
4. Что делать, когда это всё «упадет»
Перед запуском системы в продакшен вы должны понимать:

6. Подход к выбору технологий
1. Разработано и протестировано в большой компании
2. Вы знакомы с разработчиками
3. У разработчиков уже есть похожие успешные проекты
4. В документации упоминается внутреннее устройство и оно
вам понятно
Хорошими ориентирами являются:

7. Примеры успешных технологий в прошлом
• MySQL (MyISAM)
• MongoDB (MMAP)
• Memcached
• FreeBSD 4

8. Примеры успешных технологий в прошлом
• Простота и понятность архитектуры
• Работает сразу, минимум настроек
• Надежность (не «падает» на ровном месте)
• Понятные tradeoffs

9. Примеры успешных технологий в прошлом
• MySQL (MyISAM)
• MongoDB (MMAP)
• Memcached
• FreeBSD 4
скорость, простота потеря данных
скорость, простота
скорость, простота, эффективность
простота, надежность, стабильность
потеря данных

11. Tarantool: предпосылки
web1 web2 webN• • •
mysql1 mysql2 mysqlN• • •
1-1000 1001-2000 X-(X+999)
sign in for nasretdinov@gmail.com where to go?

12. Tarantool: предпосылки
web1 web2 webN• • •
mysql1 mysql2 mysqlN• • •
1-1000 1001-2000 X-(X+999)
sign in for +7 (910) 123-34-45 where to go?

13. Tarantool: предпосылки
mysql1 mysql2 mysqlN• • •
1-1000 1000-2000 X-(X+1000)
sign in for nasretdinov@gmail.com where to go?
central «authorizer» database

14. Tarantool: предпосылки
Как обновлять?
Как реплицировать?
Как рестартовать?Как добавить новые индексы?

15. Возможные решения
• Форк memcached — сложная поддержка, только в памяти
• MySQL — тяжеловесный, но есть HandlerSocket
• Redis — не поддерживает индексы
• Oracle — …
• Zookeeper — нет программируемой логики

16. Tarantool
• In-memory
• Быстрый — до 1М RPS на ядро CPU
• Конвейерная архитектура
• Написан и отлажен в mail.ru
• Константин Осипов ранее разрабатывал MySQL
• Хорошая модель персистентности — snapshots + log

17. Tarantool: архитектура
client1
client2
clientN
client3
•••
I/O Execution WAL
threads:

18. Tarantool: snapshots pre1.6.7
Parent Child
shared
private
shared
private CoW
fork
snapshot file

19. Tarantool: snapshots pre1.6.7
• Fork занимает ~10мс на 1Гб RSS
• Копирование при записи делается блоками по 4 Кб
• Общая память не помечается как CoW
• Небольшая пауза при создании snapshot

20. Tarantool: snapshots 1.6.7+
• User-space memory address translation (matras)

21. Tarantool: сценарии использования
• Очень много клиентов
• Много мелкого чтения и записи
• Необходимость в централизованном хранилище с индексами
• Желание иметь часть логики в базе
• Пример: сессии пользователей, «authorizer», счетчики
посещений

22. Tarantool: когда не использовать
• Если нужны: SQL, автоматический шардинг и failover,
Raft / Paxos, длинные транзакции
• Мало клиентов и требование минимальной latency
• Рабочий набор не влезает в память
• Аналитика (см. далее)

24. ClickHouse: предпосылки
• Эффективная и линейно масштабируемая
• В реалтайме
• Бесплатная и open-source
• ^ выберите любые два
Аналитика для веб-сайтов и приложений:

25. Возможные решения
• MySQL (MyISAM) — быстрая запись, медленное чтение
• Vertica, Exasol — платно
• Hadoop — не realtime, сложно настраивать и поддерживать
Аналитика для веб-сайтов и приложений:

26. Возможные решения
• MySQL (MyISAM) — быстрая запись, медленное чтение
• Vertica, Exasol — платно
• Hadoop — не realtime, сложно настраивать и поддерживать
Аналитика для веб-сайтов и приложений:
выбор Яндекса

27. ClickHouse
• Распределенная СУБД для аналитики
• Колоночное хранение
• Оптимизирована для HDD
• Исключительно быстрая
• Протестирована в продакшене Яндекса

28. ClickHouse: внутреннее устройство
FlightDate Month Carrier Origin Dest
• • •
Div5TailNumYear
Partition 2017-06

29. ClickHouse: «засечки»
FlightDateYear
<2017,05-01>
<2017,05-03>
<2017,05-05>
<2017,05-10>
<2017,05-15>
<2017,05-21>
<2017,05-24>
<2017,05-28>
<2017,05-30>
SELECT count()
FROM flights
WHERE year = 2017
AND FlightDate
BETWEEN ’05-11’ AND ’05-16’
Primary Key

30. ClickHouse: MergeTree
FlightDate Month Carrier Origin Dest
• • •
Div5TailNumYear
Temp Partition 2017-06 #1
Temp Partition 2017-06 #2
}FlightDate Month Carrier Origin Dest
• • •
Div5TailNumYear
FlightDate Month Carrier Origin Dest
• • •
Div5TailNumYear
Temp Partition 2017-06 #3

31. ClickHouse: возможности
• SQL, ограниченные JOIN’ы
• Репликация и работа в кластере (требуется ZooKeeper)
• 17* алгоритмов выполнения GROUP BY
• MATERIALIZED VIEWS, GLOBAL JOINs
• Выборки с сэмплированием
* наверняка их уже больше

32. ClickHouse: ограничения
• Только INSERT, нет UPDATE или DELETE
• JOIN’ы только для таблиц, которые влезают в память
• Полуручное управление кластером
• Нет полноценных транзакций, только атомарный INSERT

33. ClickHouse: сценарии использования
• Задачи realtime аналитики
• Time-series (https://github.com/yandex/graphouse)
• Хранение сырых событий — показы, клики, etc.
• Логи
• Результаты тестов

34. ClickHouse: когда не использовать
• OLTP-задачи
• Работа с деньгами
• Хранение только агрегатов
• Map / Reduce задачи
• Полнотекстовый поиск

36. CockroachDB: предпосылки
web1 web2 webN• • •
mysql1 mysql2 mysqlN• • •
sign in for nasretdinov@gmail.com where to go?
1-1000 1000-2000 X-(X+1000)

37. CockroachDB: предпосылки
web1 web2 webN• • •
mysql1 mysql2 mysqlN• • •
1-1000 1000-2000 X-(X+1000)
sign in for +7 (910) 123-34-45 where to go?

38. CockroachDB: предпосылки
CREATE TABLE users (
id INT,
email VARCHAR(200),
phone VARCHAR(30),
...,
PRIMARY KEY (id),
UNIQUE INDEX (email),
UNIQUE INDEX (phone)
)

39. CockroachDB: предпосылки
SELECT * FROM users
WHERE email = ‘nasretdinov@gmail.com’
SELECT * FROM users
WHERE phone = ‘+7 (910) 123-34-45’

40. Возможные решения
• Google Cloud Spanner
• Authorizer + ручной шардинг
• MongoDB, Cassandra — не поддерживают распределенные
уникальные индексы
• Cвой вариант?

41. CockroachDB
• Изначально — распределенный Key-Value Storage
• Production Ready (шутка) — 10 Мая вышла версия 1.0
• SQL, JOINs
• Транзакции, ACID
• Уникальные индексы
• Автоматический шардинг и балансировка нагрузки

42. CockroachDB
• Создан авторами Google Spanner
• Есть community и enterprise версии
• Написан на Go
• Использует (Multi)Raft и RocksDB
• Прошел тестирование Jepsen
• Используется в Baidu на продакшене

43. CockroachDB: SQL to KV
CREATE TABLE test (
key INT PRIMARY KEY,
floatVal FLOAT,
stringVal STRING
)
INSERT INTO test
VALUES (10, 4.5, "hello")
key value
/test/10/floatVal 4.5
/test/10/stringVal "hello"
https://www.cockroachlabs.com/blog/sql-in-cockroachdb-mapping-
table-data-to-key-value-storage/

44. CockroachDB: SQL to KV
CREATE INDEX foo ON
test (stringVal)
key value
/test/primary/10 Ø
/test/primary/10/floatVal 4.5
/test/primary/10/stringVal "hello"
/test/foo/"hello"/10 Ø
https://www.cockroachlabs.com/blog/sql-in-cockroachdb-mapping-
table-data-to-key-value-storage/

45. CockroachDB: внутреннее устройство
a - j
k - n
o - t
a - j
k - n
u - z
u - z
o - t
k - n
a - j
u - z
o - t
roach1 roach2 roach3 roach4
{64 Мб

46. CockroachDB: внутреннее устройство
a - j
k - n
o - q | r - t
a - j
k - n
u - z
u - z
o - q | r - t
k - n
a - j
u - z
o - q | r - t
roach1 roach2 roach3 roach4

47. CockroachDB: внутреннее устройство
a - j
k - n
o - q
r - t
a - j
k - n
u - z
u - z
o - q
k - n
r - t
a - j
u - z
o - q
r - t
roach1 roach2 roach3 roach4

48. CockroachDB: внутреннее устройство
a - j
k - n
o - q
r - t
a - j
k - n
u - z
u - z
o - q
k - n
r - t
a - j
u - z
o - q
r - t
roach1 roach2 roach3 roach4

49. CockroachDB: распределенные транзакции
• Есть системная таблица со списком транзакций
• К каждому затронутому в транзакции ключу добавляется
рядом ключ с номером транзакции, в которой он изменялся
• При чтении такого ключа нужно посмотреть в списке
транзакций — закоммичена она или нет
• При успешном коммите значения заменяются на конечные
• Сборщик мусора чистит неудавшиеся транзакции

50. CockroachDB: сценарии использования
• Хранение пользовательских данных в кластере вместо
MySQL / PostgreSQL / MongoDB

51. CockroachDB: когда не использовать
• Требуется низкая latency
• Требуется высокий QPS
• Не нужна строгая консистентность
• Не нужны распределенные транзакции
• Нужны сложные хранимки, JOIN’ы, представления, триггеры

52. Tarantool (memtx)
• extreme RPS
• eventual consistency
• single-core
• in-memory
• manual sharding

53. ClickHouse
• auto parallelize
• HDD-optimized
• extreme throughput (scan 10^9 rows/sec per node)
• in-memory, limited joins
• no transactions, update/delete/replace
• semi-automatic cluster management

54. CockroachDB
• linear auto scaling
• ACID, distributed transactions
• supports standard SQL
• 1.0 just released
• limited joins
• poor performance (~ 1k RPS per node)

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

56. Вопросы
Юрий Насретдинов
nasretdinov@gmail.com