Обзор перспективных баз данных для highload / Юрий Насретдинов
1 like1,833 views
Доклад Юрия Насретдинова рассматривает перспективные СУБД для highload приложений, включая Tarantool, ClickHouse и CockroachDB. Он подчеркивает важность осмысленного выбора технологий, учитывающего архитектуру, мониторинг и возможные слабые места. Доклад завершает оценка применения каждой базы данных в различных сценариях, акцентируя внимание на их сильных и слабых сторонах.
Обзор перспективных баз данных для highload / Юрий Насретдинов
- 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 [email protected] 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 [email protected] 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
- 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 [email protected] 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 = ‘[email protected]’ 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 новые базы данных и про то, где их применять • Думайте своей головой перед тем, как применять их в продакшене