Доклад рассматривает архитектуру и функциональные возможности системы хранения данных на виниле, включая структуру log structured merge tree и реализацию vinyl engine в Tarantool. Обсуждаются преимущества и недостатки LSM-деревьев, проблемы с производительностью, а также методы уменьшения задержки чтения и записи данных. В заключение представляются аспекты репликации и ограничения использования системы.

1. Хранение данных на виниле
kostja@tarantool.org
Konstantin Osipov

2. План доклада
● вводный обзор log structured merge tree
● Устройство vinyl engine в Tarantool
● варианты использования
● планы

3. Классическое LSM

4. DELETE в LSM tree
● нет возможности удалять из всех уровней
● вставляется маркер удаления

5. SELECT в LSM tree
● ищет во всех уровнях, пока не найдёт нужный ключ
● слияние результатов поиска

6. LSM: алгортмический потолок
LSM tree B-tree
Search K * O(log N/B) O(logB N)
Delete O(logB N/Bε) O(logB N)
Insert O(logB N/Bε) O(logB N)

7. RUM conjecture

8. Проблемы применения LSM в Web/OLTP
1. Медленные чтения: read amplification
2. Потенциально очень много пишем на диск, много больше
чем сами данные: write amplification
3. Храним мусор: space amplification
4. Непредсказуемая работа в моменты перестроения дерева:
latency spikes

9. Vinyl: memtable, sorted run, dump & merge
● хранит операции, а не данные: REPLACE, DELETE, UPSERT
● каждое значение помечено LSN
● append-only, garbage collection, message passing

10. Vinyl: чтение

11. Делаем latency предсказуемым
● упреждающие dumpы
● throttling

12. Снижаем read amplification
● page index
● tuple range cache
● multi-level compaction

13. Снижаем write amplification
● multi-level compaction
● ranges

14. Снижаем space amplification
● ranges

15. Поддержка вторичных ключей
● хранят значение вторичного и первичного ключа
● нивелируют преимущества REPLACE/UPSERT

16. UPSERT
● non-reading update or insert
● отложенное выполнение
● есть только в Tarantool
● squashing

17. Планировщик
● единственная активная сущность в Vinyl
● обрабатывает две очереди: dump и merge
● очереди содержат все ranges

18. Transactions
● MVCC
● the first transaction to commit wins
● no waits, no deadlocks, only aborts
● yields don’t abort transactions

19. Репликация
Работает из коробки

20. Ограничения
● небольшие таплы
● помните об оверхеде вторичных ключей
● несколько тысяч файловых дескрипторов
● просто планировщик транзакций: долгие read-write
транзакции могут абортиться
● нет cross-engine транзакций
● space amplification требует до 2х резервирования

21. Ссылки
Leveled compaction in Apache Cassandra
http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra
http://www.scylladb.com/kb/compaction/
https://github.com/facebook/rocksdb/wiki/Universal-Compaction
https://dom.as/2015/04/09/how-innodb-lost-its-advantage/

22. @kostja_osipov
Thank you!
fb.com/TarantoolDatabase
www.tarantool.orgkostja@tarantool.org

23. Делаем latency предсказуемым
● упреждающие dumpы
● throttling