За счет чего Tarantool такой оптимальный / Денис Аникин...

За счет чего Tarantool такой оптимальный

Денис Аникин, технический директор почтовых и облачных сервисов в Mail.Ru Group

Что ожидать от этого доклада• рассказ о конкретике про устройство Tarantool, которая делает его

оптимальным по сравнению с другими СУБД• упоминание причин, побудивших нас сделать его таким

оптимальным

Чего не стоит ждать от этого доклада• Holy wars. Все СУБД хороши для своих задач• Супер новых структур данных и алгоритмов• Логарифм от N логаримфу от N рознь

Tarantool хранит копию данных в памятиВ отличие от дисковой базы данных

• нет обращений к диску во время операций чтения• нет накладных расходов на кэширование и выгрузку страниц• запись на диск происходит всегда линейно• линейное чтение snapshot => максимально быстрый старт

Поэтому он быстрее дисковых баз данных

Tarantool RAMRead

Disk based

database

ReadDISK

А как же кэш у дисковых баз?

Давайте сравним in-memory Tarantool

Tarantool RAMRead

И кэш у дисковых базDisk

based database

Yes

Check cache

Read from cache

Read from disk

Write to cache

Read

No

Evict old

Почувствуйте разницу!

Tarantool хранит копию данных в памяти

Always in-memory != Cache

А как происходит запись на диск?

А как происходит запись на диск?

RAM

TRANSACTIONLOG

TARANTOOL

QUERIES

UPDATES

UPDATES

Запись на диск – в деталях

TRANSACTIONLOG SO FAR

THE NEXT TRANSACTION

THE NEXT TRANSACTION

THE NEXT TRANSACTION

New transactions all apply at the end of the log

Доктор, это не медленно?

TRANSACTIONLOG SO FAR

THE NEXT TRANSACTION

THE NEXT TRANSACTION

THE NEXT TRANSACTION

New transactions all apply at the end of the log

Доктор, это не медленно?

TRANSACTIONLOG SO FAR

THE NEXT TRANSACTION

THE NEXT TRANSACTION

THE NEXT TRANSACTION

New transactions all apply at the end of the log

HDD – 100Mb/sSSD - 250Mb/s

Доктор, это не медленно?

TRANSACTIONLOG SO FAR

THE NEXT TRANSACTION

THE NEXT TRANSACTION

THE NEXT TRANSACTION

New transactions all apply at the end of the log

HDD – 100Mb/sSSD - 250Mb/s

При размере транзакции 100 байтэто от 1 mln TPS

А как дисковые базы пишут на диск?

Они делают все, что Tarantool, плюс …

RAM

TRANSACTIONLOG

DISK DATABASE

QUERIES

UPDATES

UPDATES

… плюс обновляют данные на диске (как?)

… обновляют данные на диске в дереве

BLOCKB-Tree

BLOCK BLOCK BLOCK

BLOCK BLOCK BLOCK BLOCK BLOCK

… обновляют данные на диске в дереве

• Это случайное обращение к диску• На HDD – это в лучшем случае 100 обращений в секунду• На SSD – 1000-5000 обращений в секунду

Tarantool. Старт

TarantoolRead Snapshot

&log

Tarantool. Старт. Как быстро?

TarantoolRead Snapshot

&log

Tarantool. Старт. Довольно быстро

TarantoolRead Snapshot

&log

HDD – 100Mb/sSSD - 250Mb/s

А дисковые базы данных как стартуют?

А дисковые базы данных как стартуют?

• Надо отдать им должное, стартуют почти моментально

А дисковые базы данных как стартуют?

• Надо отдать им должное, стартуют почти моментально• Но …

А дисковые базы данных как стартуют?

• Надо отдать им должное, стартуют почти моментально• Но начинают нормально работать после прогрева кэша

А дисковые базы данных как стартуют?

• Надо отдать им должное, стартуют почти моментально• Но начинают нормально работать после прогрева кэша• Бывалые DBA знают различные техники прогрева

А дисковые базы данных как стартуют?

• Надо отдать им должное, стартуют почти моментально• Но начинают нормально работать после прогрева кэша• Бывалые DBA знают различные техники прогрева• А как в целом прогревается кэш?

Как прогревается кэш?

Как прогревается кэш?

Disk based

database

Random readDISK

User

Как прогревается кэш?

Disk based

database

Random readDISK

User Практика Mail.Ru c MySQL – 1-2 Mb/s

Как прогревается кэш?

1-2 Mb/s vs 100-250 Mb/s

Разница в 100 раз!

Как прогревается кэш?

• Tarantool готов к работе гораздо раньше дисковых баз• И не потому что магия, а потому что in-memory• Горячие данные сгруппированы, не размазаны по диску

А теперь давайте поговорим о latency

Latency spikes в Mail.Ru по ночамКаждую ночь latency вырастала в 1000 раз в течение минуты

В чем причина?

Ну, явно же не в нагрузке от пользователей. Они спят по ночам обычно

Причина – ночной snapshotting• snapshotting – это дамп всей базы с целью сжатия лога• начиная с Tarantool 1.6.6 мы полностью переделали snapshotting• не затормаживая поток обработки транзакций• почти без лишних выделений памяти

Почему snapshotting тормозит все?

Потому что fork()

Tarantoolparent

Snapshot by fork()

DISKTarantool

child

Почему fork() – это зло для snapshotting?

Механизм copy-on-write в fork() вызывает массовые выделения страниц и копирование

Tarantoolparent

Snapshot by fork()

DISKTarantool

child

Memory Memory

Copy-on-write

А как у других in-memory баз данных?

Tarantoolparent

Snapshot by fork()

DISKTarantool

child

Memory Memory

Copy-on-write

Кстати, Redis делает так же

fork(). Как сделать лучше?

Tarantoolparent

Snapshot by fork()

DISKTarantool

child

Memory Memory

Copy-on-write

Кстати, Redis делает так же

Заменить copy-on-write на собственный механизм

Tarantoolparent

Snapshot by fork()

DISKTarantool

child

Memory Memory

Copy-on-writeСобственный механизм

MVCC• Во время snapshotting изменения делаем копированием• У каждого элемента несколько версий• При изменениях создаются новые версии• Копируем не 4K, а лишь несколько байт• Не копируем таблицы дескрипторов

Latency spikes пропали. Все работает быстро. Даже ночью

Узкие места в базе данных

Узкие места в базе данных• во сколько раз хэш из C++ быстрее индекса в базе данных?

Узкие места в базе данных• во сколько раз хэш из C++ быстрее индекса в базе данных?• std::unordered_map – 2 млн. операций в секунду (на 1 ядре)

Узкие места в базе данных• во сколько раз хэш из C++ быстрее индекса в базе данных?• std::unordered_map – 2 млн. операций в секунду (на 1 ядре)• индекс – в лучшем случае 10К операций в секунду (на 1 ядре)

Узкие места в базе данных• во сколько раз хэш из C++ быстрее индекса в базе данных?• std::unordered_map – 2 млн. операций в секунду (на 1 ядре)• индекс – в лучшем случае 10К операций в секунду (на 1 ядре)• Разница в 100 раз! Почему?

Узкие места в базе данных• во сколько раз хэш из C++ быстрее индекса в базе данных?• std::unordered_map – 2 млн. операций в секунду (на 1 ядре)• индекс – в лучшем случае 10К операций в секунду (на 1 ядре)• Разница в 100 раз! Почему?• Системные вызовы!

Откуда системные вызовы?• Считать запрос из сети (read)• Заблокировать (mutex)• Разблокировать (mutex)• Записать в лог транзакцию (write)• Записать ответ в сеть (write)

Почему системные вызовы дорогие?• Скопировать контекст (скопировать сотни байт минимум)• Войти в режим ядра• Восстановить контекст (скопировать сотни байт минимум)• Выйти из режима ядра

Как Tarantool решает эти проблемы?• Асинхронный протокол – используем сокет параллельно• Пакетная работа с сетью• Пакетная работа с диском• Меньше syscalls, меньше переходов в режим ядра и обратно

Как Tarantool решает эти проблемы?

Clients

REQUEST

Network thread TX Disk thread

REQUEST

RESPONSE

GROUP OF REQUESTS

PROCESS IN-MEMORY

BEGINLOG GROUP

MARK EACH OF GROUP

COMMITTEDGROUP OF RESPONSES

ENDLOG GROUP

На сегодня все!

Что я не рассказал• Zero copy (почти нет копирований)• Собственные структуры данных (tree, hash)• Собственный алокатор• Однопоточный процессор транзакций – нет накладных расходов

на блокировки• Параллельность на fibers, а не на threads => меньше

переключений контекста• И многое другое …

http://sh5.tarantool.org• В завершение хочу рассказать про нетехнический метод

поддержки оптимальности• У нас есть специальная система, которая проверяет

производительность по каждому коммиту и по многим параметрам

Кстати, она, как и весь код Tarantool, открытаи позволяет нам держать себя в форме

Вопросы?• Буду рад ответить на все ваши вопросы• А также подходите в экспертную зону Tarantool• Если вопросы останутся после доклада, то не стесняйтесь писать на

support@tarantool.org или на anikin@corp.mail.ru• Также посетите наш сайт https://tarantool.org• Или наш твиттер https://twitter.com/TarantoolDB• Кроме того, мы рады ответить на ваши вопросы в гугловой группе:

https://groups.google.com/forum/#!forum/tarantool• И на stackoverflow: https://stackoverflow.com/questions/tagged/tarantool