РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
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. В документации упоминается внутреннее устройство и оно
вам понятно
Хорошими ориентирами являются:
8. Примеры успешных технологий в прошлом
• Простота и понятность архитектуры
• Работает сразу, минимум настроек
• Надежность (не «падает» на ровном месте)
• Понятные tradeoffs
9. Примеры успешных технологий в прошлом
• MySQL (MyISAM)
• MongoDB (MMAP)
• Memcached
• FreeBSD 4
скорость, простота потеря данных
скорость, простота
скорость, простота, эффективность
простота, надежность, стабильность
потеря данных
10.
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
15. Возможные решения
• Форк memcached — сложная поддержка, только в памяти
• MySQL — тяжеловесный, но есть HandlerSocket
• Redis — не поддерживает индексы
• Oracle — …
• Zookeeper — нет программируемой логики
16. Tarantool
• In-memory
• Быстрый — до 1М RPS на ядро CPU
• Конвейерная архитектура
• Написан и отлажен в mail.ru
• Константин Осипов ранее разрабатывал MySQL
• Хорошая модель персистентности — snapshots + log
19. Tarantool: snapshots pre1.6.7
• Fork занимает ~10мс на 1Гб RSS
• Копирование при записи делается блоками по 4 Кб
• Общая память не помечается как CoW
• Небольшая пауза при создании snapshot
21. Tarantool: сценарии использования
• Очень много клиентов
• Много мелкого чтения и записи
• Необходимость в централизованном хранилище с индексами
• Желание иметь часть логики в базе
• Пример: сессии пользователей, «authorizer», счетчики
посещений
22. Tarantool: когда не использовать
• Если нужны: SQL, автоматический шардинг и failover,
Raft / Paxos, длинные транзакции
• Мало клиентов и требование минимальной latency
• Рабочий набор не влезает в память
• Аналитика (см. далее)
23.
24. ClickHouse: предпосылки
• Эффективная и линейно масштабируемая
• В реалтайме
• Бесплатная и open-source
• ^ выберите любые два
Аналитика для веб-сайтов и приложений:
25. Возможные решения
• MySQL (MyISAM) — быстрая запись, медленное чтение
• Vertica, Exasol — платно
• Hadoop — не realtime, сложно настраивать и поддерживать
Аналитика для веб-сайтов и приложений:
26. Возможные решения
• MySQL (MyISAM) — быстрая запись, медленное чтение
• Vertica, Exasol — платно
• Hadoop — не realtime, сложно настраивать и поддерживать
Аналитика для веб-сайтов и приложений:
выбор Яндекса
27. ClickHouse
• Распределенная СУБД для аналитики
• Колоночное хранение
• Оптимизирована для HDD
• Исключительно быстрая
• Протестирована в продакшене Яндекса
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 задачи
• Полнотекстовый поиск
35.
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/
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: распределенные транзакции
• Есть системная таблица со списком транзакций
• К каждому затронутому в транзакции ключу добавляется
рядом ключ с номером транзакции, в которой он изменялся
• При чтении такого ключа нужно посмотреть в списке
транзакций — закоммичена она или нет
• При успешном коммите значения заменяются на конечные
• Сборщик мусора чистит неудавшиеся транзакции
51. CockroachDB: когда не использовать
• Требуется низкая latency
• Требуется высокий QPS
• Не нужна строгая консистентность
• Не нужны распределенные транзакции
• Нужны сложные хранимки, JOIN’ы, представления, триггеры
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 новые базы данных и про то, где их
применять
• Думайте своей головой перед тем, как применять их в
продакшене