Upload
ontico
View
154
Download
8
Embed Size (px)
Citation preview
За счет чего 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• Если вопросы останутся после доклада, то не стесняйтесь писать на
[email protected] или на [email protected]• Также посетите наш сайт https://tarantool.org• Или наш твиттер https://twitter.com/TarantoolDB• Кроме того, мы рады ответить на ваши вопросы в гугловой группе:
https://groups.google.com/forum/#!forum/tarantool• И на stackoverflow: https://stackoverflow.com/questions/tagged/tarantool