Downloaded 20 times
Uploaded byOntico
За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)
Доклад Дениса Аникина, технического директора mail.ru, описывает оптимальность Tarantool по сравнению с другими СУБД благодаря хранению данных в памяти и минимизации операций записи на диск. Он выделяет использование логов транзакций и асинхронных протоколов как ключевые аспекты повышения производительности, а также обсуждает механизмы управления латентностью. Tarantool способен быстрее обрабатывать запросы и значительно снижает затраты на системные вызовы, что делает его эффективным инструментом для работы с данными.
More Related Content
Similar to За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)
За счет чего Tarantool такой оптимальный / Денис Аникин (Mail.Ru)
- 1. За счет чегоTarantool такой оптимальный Денис Аникин, технический директор почтовых и облачных сервисов в Mail.Ru Group
- 2. Что ожидать отэтого доклада • рассказ о конкретике про устройство Tarantool, которая делает его оптимальным по сравнению с другими СУБД • упоминание причин, побудивших нас сделать его таким оптимальным
- 3. Чего не стоитждать от этого доклада • Holy wars. Все СУБД хороши для своих задач • Супер новых структур данных и алгоритмов • Логарифм от N логаримфу от N рознь
- 4. Tarantool хранит копиюданных в памяти В отличие от дисковой базы данных • нет обращений к диску во время операций чтения • нет накладных расходов на кэширование и выгрузку страниц • запись на диск происходит всегда линейно • линейное чтение snapshot => максимально быстрый старт
- 5. Поэтому он быстреедисковых баз данных Tarantool RAM Read Disk based database Read DISK
- 6. А как жекэш у дисковых баз?
- 7. Давайте сравним in-memoryTarantool Tarantool RAM Read
- 8. И кэш удисковых баз Disk based database Yes Check cache Read from cache Read from disk Write to cache Read No Evict old
- 9.
- 10. Tarantool хранит копиюданных в памяти Always in-memory != Cache
- 11. А как происходитзапись на диск?
- 12. А как происходитзапись на диск? RAM TRANSACTION LOG TARANTOOL QUERIES UPDATES UPDATES
- 13. Запись на диск– в деталях TRANSACTION LOG SO FAR THE NEXT TRANSACTION THE NEXT TRANSACTION THE NEXT TRANSACTION New transactions all apply at the end of the log
- 14. Доктор, это немедленно? TRANSACTION LOG SO FAR THE NEXT TRANSACTION THE NEXT TRANSACTION THE NEXT TRANSACTION New transactions all apply at the end of the log
- 15. Доктор, это немедленно? TRANSACTION LOG SO FAR THE NEXT TRANSACTION THE NEXT TRANSACTION THE NEXT TRANSACTION New transactions all apply at the end of the log HDD – 100Mb/s SSD - 250Mb/s
- 16. Доктор, это немедленно? TRANSACTION LOG SO FAR THE NEXT TRANSACTION THE NEXT TRANSACTION THE NEXT TRANSACTION New transactions all apply at the end of the log HDD – 100Mb/s SSD - 250Mb/s При размере транзакции 100 байт это от 1 mln TPS
- 17. А как дисковыебазы пишут на диск?
- 18. Они делают все,что Tarantool, плюс … RAM TRANSACTION LOG DISK DATABASE QUERIES UPDATES UPDATES
- 19. … плюс обновляютданные на диске (как?)
- 20. … обновляют данныена диске в дереве BLOCKB-Tree BLOCK BLOCK BLOCK BLOCK BLOCK BLOCK BLOCK BLOCK
- 21. … обновляют данныена диске в дереве • Это случайное обращение к диску • На HDD – это в лучшем случае 100 обращений в секунду • На SSD – 1000-5000 обращений в секунду
- 22.
- 23. Tarantool. Старт. Какбыстро? Tarantool Read Snapshot & log
- 24. Tarantool. Старт. Довольнобыстро Tarantool Read Snapshot & log HDD – 100Mb/s SSD - 250Mb/s
- 25. А дисковые базыданных как стартуют?
- 26. А дисковые базыданных как стартуют? • Надо отдать им должное, стартуют почти моментально
- 27. А дисковые базыданных как стартуют? • Надо отдать им должное, стартуют почти моментально • Но …
- 28. А дисковые базыданных как стартуют? • Надо отдать им должное, стартуют почти моментально • Но начинают нормально работать после прогрева кэша
- 29. А дисковые базыданных как стартуют? • Надо отдать им должное, стартуют почти моментально • Но начинают нормально работать после прогрева кэша • Бывалые DBA знают различные техники прогрева
- 30. А дисковые базыданных как стартуют? • Надо отдать им должное, стартуют почти моментально • Но начинают нормально работать после прогрева кэша • Бывалые DBA знают различные техники прогрева • А как в целом прогревается кэш?
- 31.
- 32. Как прогревается кэш? Disk based database Randomread DISK User
- 33. Как прогревается кэш? Disk based database Randomread DISK User Практика Mail.Ru c MySQL – 1-2 Mb/s
- 34. Как прогревается кэш? 1-2Mb/s vs 100-250 Mb/s Разница в 100 раз!
- 35. Как прогревается кэш? •Tarantool готов к работе гораздо раньше дисковых баз • И не потому что магия, а потому что in-memory • Горячие данные сгруппированы, не размазаны по диску
- 36. А теперь давайтепоговорим о latency
- 37. Latency spikes вMail.Ru по ночам Каждую ночь latency вырастала в 1000 раз в течение минуты
- 38. В чем причина? Ну,явно же не в нагрузке от пользователей. Они спят по ночам обычно
- 39. Причина – ночнойsnapshotting • snapshotting – это дамп всей базы с целью сжатия лога • начиная с Tarantool 1.6.6 мы полностью переделали snapshotting • не затормаживая поток обработки транзакций • почти без лишних выделений памяти
- 40.
- 41. Потому что fork() Tarantool parent Snapshotby fork() DISK Tarantool child Почему fork() – это зло для snapshotting?
- 42. Механизм copy-on-write вfork() вызывает массовые выделения страниц и копирование Tarantool parent Snapshot by fork() DISK Tarantool child Memory Memory Copy-on-write
- 43. А как удругих in-memory баз данных? Tarantool parent Snapshot by fork() DISK Tarantool child Memory Memory Copy-on-write Кстати, Redis делает так же
- 44. fork(). Как сделатьлучше? Tarantool parent Snapshot by fork() DISK Tarantool child Memory Memory Copy-on-write Кстати, Redis делает так же
- 45. Заменить copy-on-write насобственный механизм Tarantool parent Snapshot by fork() DISK Tarantool child Memory Memory Copy-on-write Собственный механизм
- 46. MVCC • Во времяsnapshotting изменения делаем копированием • У каждого элемента несколько версий • При изменениях создаются новые версии • Копируем не 4K, а лишь несколько байт • Не копируем таблицы дескрипторов
- 48. Latency spikes пропали.Все работает быстро. Даже ночью
- 49. Узкие места вбазе данных
- 50. Узкие места вбазе данных • во сколько раз хэш из C++ быстрее индекса в базе данных?
- 51. Узкие места вбазе данных • во сколько раз хэш из C++ быстрее индекса в базе данных? • std::unordered_map – 2 млн. операций в секунду (на 1 ядре)
- 52. Узкие места вбазе данных • во сколько раз хэш из C++ быстрее индекса в базе данных? • std::unordered_map – 2 млн. операций в секунду (на 1 ядре) • индекс – в лучшем случае 10К операций в секунду (на 1 ядре)
- 53. Узкие места вбазе данных • во сколько раз хэш из C++ быстрее индекса в базе данных? • std::unordered_map – 2 млн. операций в секунду (на 1 ядре) • индекс – в лучшем случае 10К операций в секунду (на 1 ядре) • Разница в 100 раз! Почему?
- 54. Узкие места вбазе данных • во сколько раз хэш из C++ быстрее индекса в базе данных? • std::unordered_map – 2 млн. операций в секунду (на 1 ядре) • индекс – в лучшем случае 10К операций в секунду (на 1 ядре) • Разница в 100 раз! Почему? • Системные вызовы!
- 55. Откуда системные вызовы? •Считать запрос из сети (read) • Заблокировать (mutex) • Разблокировать (mutex) • Записать в лог транзакцию (write) • Записать ответ в сеть (write)
- 56. Почему системные вызовыдорогие? • Скопировать контекст (скопировать сотни байт минимум) • Войти в режим ядра • Восстановить контекст (скопировать сотни байт минимум) • Выйти из режима ядра
- 57. Как Tarantool решаетэти проблемы? • Асинхронный протокол – используем сокет параллельно • Пакетная работа с сетью • Пакетная работа с диском • Меньше syscalls, меньше переходов в режим ядра и обратно
- 58. Как Tarantool решаетэти проблемы? Clients REQUEST Network thread TX Disk thread REQUEST RESPONSE GROUP OF REQUESTS PROCESS IN- MEMORY BEGIN LOG GROUP MARK EACH OF GROUP COMMITTED GROUP OF RESPONSES END LOG GROUP
- 59.
- 60. Что я нерассказал • Zero copy (почти нет копирований) • Собственные структуры данных (tree, hash) • Собственный алокатор • Однопоточный процессор транзакций – нет накладных расходов на блокировки • Параллельность на fibers, а не на threads => меньше переключений контекста • И многое другое …
- 61. http://sh5.tarantool.org • В завершениехочу рассказать про нетехнический метод поддержки оптимальности • У нас есть специальная система, которая проверяет производительность по каждому коммиту и по многим параметрам
- 62. Кстати, она, каки весь код Tarantool, открыта и позволяет нам держать себя в форме
- 63. Вопросы? • Буду радответить на все ваши вопросы • А также подходите в экспертную зону 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