Юрий Насретдинов · 2017-06-13 · Обо мне • Зовут Юрий, в...
Post on 08-Feb-2020
10 Views
Preview:
TRANSCRIPT
Обзор перспективных СУБД для 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 nasretdinov@gmail.com where to go?
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?
Tarantool: предпосылкиsign in for nasretdinov@gmail.com where to go?
central «authorizer» database
mysql1 mysql2 mysqlN• • •1-1000 1001-2000 X-(X+999)
Tarantool: предпосылки
Как обновлять?Как реплицировать?
Как рестартовать?Как добавить новые индексы?
Возможные решения• Форк memcached — сложная поддержка, только в памяти
• MySQL — тяжеловесный, но есть HandlerSocket
• Redis — не поддерживает индексы
• Oracle — …
• Zookeeper — нет программируемой логики
Tarantool• In-memory
• Быстрый — до 1М RPS на ядро CPU
• Конвейерная архитектура
• Написан и отлажен в mail.ru
• Константин Осипов ранее разрабатывал MySQL
• Хорошая модель персистентности — snapshots + log
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.
• Логи
• Результаты тестов
ClickHouse: когда не использовать
• OLTP-задачи
• Работа с деньгами
• Хранение только агрегатов
• Map / Reduce задачи
• Полнотекстовый поиск
Tarantool: предпосылки
web1 web2 webN• • •
mysql1 mysql2 mysqlN• • •1-1000 1001-2000 X-(X+999)
sign in for nasretdinov@gmail.com where to go?
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?
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 = ‘nasretdinov@gmail.com’
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/
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 Мб
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
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
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
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 новые базы данных и про то, где их применять
• Думайте своей головой перед тем, как применять их в продакшене
top related