Многие из вас, наверное, видели результаты тестов сравнения Tarantool с остальными СУБД, которые показывают, что Tarantool быстрее всех, оптимальней по памяти, обрабатывает наибольшее количество транзакций в секунду. И, несмотря на то, что исходные коды всех тестов полностью открыты и хорошо откомментированы, позволяя всем желающим повторить тесты, все равно остаются вопросы - за счет чего Tarantool такой быстрый и оптимальный? Я решил суммировать мои ответы на эти вопросы в докладе на Highload++. Итак, почему Tarantool такой быстрый? Краткий ответ: потому что он с самого начала разрабатывался и до сих пор разрабатывается во главе угла с производительностью/оптимальностью/минимальным потреблением всех ресурсов системы. Более полный ответ я раскрою в своем выступлении. Приходите, будет интересно! :)

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-memory Tarantool
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. Tarantool. Старт
Tarantool
Read Snapshot
&
log

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
Random read
DISK
User

33. Как прогревается кэш?
Disk
based
database
Random read
DISK
User Практика Mail.Ru c MySQL – 1-2 Mb/s

34. Как прогревается кэш?
1-2 Mb/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. Почему snapshotting тормозит все?

41. Потому что fork()
Tarantool
parent
Snapshot by
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