Юрий Насретдинов · 2017-06-13 · Обо мне • Зовут Юрий, в...

Обзор перспективных СУБД для highload

Юрий Насретдинов

План• Обо мне

• Подход к выбору технологий

• Tarantool

• ClickHouse

• CockroachDB

• Заключение

Обо мне• Зовут Юрий, в честь дедушки

• Написал свою СУБД на PHP

• Работал в Badoo ~5 лет в отделе «платформы»

• 10 лет опыта программирования на PHP

• Сейчас разрабатываю на Go

Зачем этот доклад?

• Индустрия IT быстро развивается

• Highload — тем более

• Через 10 лет ваши сегодняшние знания и навыки безнадежно устареют

Подход к выбору технологий

1. Архитектуру

2. Не только сильные, но и слабые места

3. Как «это» мониторить и бэкапить

4. Что делать, когда это всё «упадет»

Перед запуском системы в продакшен вы должны понимать:

Подход к выбору технологий

1. Разработано и протестировано в большой компании

2. Вы знакомы с разработчиками

3. У разработчиков уже есть похожие успешные проекты

4. В документации упоминается внутреннее устройство и оно вам понятно

Хорошими ориентирами являются:

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

• MySQL (MyISAM)

• MongoDB (MMAP)

• Memcached

• FreeBSD 4


• Простота и понятность архитектуры

• Работает сразу, минимум настроек

• Надежность (не «падает» на ровном месте)

• Понятные tradeoffs


• MySQL (MyISAM)

• MongoDB (MMAP)

• Memcached

• FreeBSD 4

скорость, простота потеря данных

скорость, простота, эффективность

простота, надежность, стабильность

скорость, простота потеря данных

Tarantool: предпосылки

web1 web2 webN• • •

mysql1 mysql2 mysqlN• • •1-1000 1001-2000 X-(X+999)

sign in for [email protected] where to go?

mailto:[email protected]




sign in for +7 (910) 123-34-45 where to go?

Tarantool: предпосылкиsign in for [email protected] where to go?

central «authorizer» database




Как обновлять?Как реплицировать?

Как рестартовать?Как добавить новые индексы?

Возможные решения• Форк memcached — сложная поддержка, только в памяти

• MySQL — тяжеловесный, но есть HandlerSocket

• Redis — не поддерживает индексы

• Oracle — …

• Zookeeper — нет программируемой логики

Tarantool• In-memory

• Быстрый — до 1М RPS на ядро CPU

• Конвейерная архитектура

• Написан и отлажен в mail.ru

• Константин Осипов ранее разрабатывал MySQL

• Хорошая модель персистентности — snapshots + log

http://mail.ru

Tarantool: архитектура

client1

client2

clientN

client3

• •

•

I/O Execution WALthreads:

Tarantool: snapshots pre1.6.7

Parent Child

shared

private

shared

private CoW

forksnapshot file

Tarantool: snapshots pre1.6.7

• Fork занимает ~10мс на 1Гб RSS

• Копирование при записи делается блоками по 4 Кб

• Общая память не помечается как CoW

• Небольшая пауза при создании snapshot

Tarantool: snapshots 1.6.7+

• User-space memory address translation (matras)

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

• Очень много клиентов

• Много мелкого чтения и записи

• Необходимость в централизованном хранилище с индексами

• Желание иметь часть логики в базе

• Пример: сессии пользователей, «authorizer», счетчики посещений

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

• Если нужны: SQL, автоматический шардинг и failover, Raft / Paxos, длинные транзакции

• Мало клиентов и требование минимальной latency

• Рабочий набор не влезает в память

• Аналитика (см. далее)

ClickHouse: предпосылки

• Эффективная и линейно масштабируемая

• В реалтайме

• Бесплатная и open-source

• ^ выберите любые два

Аналитика для веб-сайтов и приложений:

Возможные решения

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

• Vertica, Exasol — платно

• Hadoop — не realtime, сложно настраивать и поддерживать



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

• Vertica, Exasol — платно

• Hadoop — не realtime, сложно настраивать и поддерживать


выбор Яндекса

ClickHouse• Распределенная СУБД для аналитики

• Колоночное хранение

• Оптимизирована для HDD

• Исключительно быстрая

• Протестирована в продакшене Яндекса

ClickHouse: внутреннее устройство

FlightDate Month Carrier Origin Dest

• • •

Div5TailNumYear

Partition 2017-06

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

ClickHouse: MergeTreeFlightDate 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

• • •

ClickHouse: возможности• SQL, ограниченные JOIN’ы

• Репликация и работа в кластере (требуется ZooKeeper)

• 17* алгоритмов выполнения GROUP BY

• MATERIALIZED VIEWS, GLOBAL JOINs

• Выборки с сэмплированием* наверняка их уже больше

ClickHouse: ограничения

• Только INSERT, нет UPDATE или DELETE

• JOIN’ы только для таблиц, которые влезают в память

• Полуручное управление кластером

• Нет полноценных транзакций, только атомарный INSERT

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

• Задачи realtime аналитики

• Time-series (https://github.com/yandex/graphouse)

• Хранение сырых событий — показы, клики, etc.

• Логи

• Результаты тестов

https://github.com/yandex/graphouse

https://github.com/yandex/graphouse

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

• OLTP-задачи

• Работа с деньгами

• Хранение только агрегатов

• Map / Reduce задачи

• Полнотекстовый поиск




sign in for [email protected] where to go?





sign in for +7 (910) 123-34-45 where to go?

CockroachDB: предпосылки

CREATE TABLE users ( id INT, email VARCHAR(200), phone VARCHAR(30), ..., PRIMARY KEY (id), UNIQUE INDEX (email), UNIQUE INDEX (phone) )

CockroachDB: предпосылки

SELECT * FROM users WHERE email = ‘[email protected]’

SELECT * FROM users WHERE phone = ‘+7 (910) 123-34-45’


• Google Cloud Spanner

• Authorizer + ручной шардинг

• MongoDB, Cassandra — не поддерживают распределенные уникальные индексы

• Cвой вариант?

CockroachDB• Изначально — распределенный Key-Value Storage

• Production Ready (шутка) — 10 Мая вышла версия 1.0

• SQL, JOINs

• Транзакции, ACID

• Уникальные индексы

• Автоматический шардинг и балансировка нагрузки

CockroachDB• Создан авторами Google Spanner

• Есть community и enterprise версии

• Написан на Go

• Использует (Multi)Raft и RocksDB

• Прошел тестирование Jepsen

• Используется в Baidu на продакшене

CockroachDB: SQL to KVCREATE 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/

https://www.cockroachlabs.com/blog/sql-in-cockroachdb-mapping-table-data-to-key-value-storage/



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/





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 Мб


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



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


CockroachDB: распределенные транзакции

• Есть системная таблица со списком транзакций

• К каждому затронутому в транзакции ключу добавляется рядом ключ с номером транзакции, в которой он изменялся

• При чтении такого ключа нужно посмотреть в списке транзакций — закоммичена она или нет

• При успешном коммите значения заменяются на конечные

• Сборщик мусора чистит неудавшиеся транзакции

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

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

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

• Требуется низкая latency

• Требуется высокий QPS

• Не нужна строгая консистентность

• Не нужны распределенные транзакции

• Нужны сложные хранимки, JOIN’ы, представления, триггеры

Tarantool (memtx)• extreme RPS

• eventual consistency

• single-core

• in-memory

• manual sharding

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

CockroachDB• linear auto scaling

• ACID, distributed transactions

• supports standard SQL

• 1.0 just released

• limited joins

• poor performance (~ ? RPS per node)

Заключение

• Теперь вы узнали про 3 новые базы данных и про то, где их применять

• Думайте своей головой перед тем, как применять их в продакшене

Вопросы

Юрий Насретдинов

[email protected]


Юрий Насретдинов · 2017-06-13 · Обо мне • Зовут Юрий, в...

Documents

Transcript of Юрий Насретдинов · 2017-06-13 · Обо мне • Зовут Юрий, в...