В rfc1149 дан исчерпывающий обзор преимуществ голубиной почты для протокола IP: низкая пропускная способность, невысокая надёжность, простая топология сети. Для того чтобы дать адекватный ответ вызовам эпохи мемристоров и квантовых вычислений, Tarantool 1.7 содержит новый движок для хранения данных на классических жёстких дисках и флэш-накопителях: Vinyl. Tarantool известен своей скоростью, и мы постарались не ударить в грязь лицом и на этот раз. В докладе я расскажу об устройстве нашего нового storage engine: - как мы объединили in-memory технологию и LSM (log structured merge) деревья для достижения оптимальной производительности и утилизации ресурса накопителя, - как работает multiversion concurrency control в Vinyl, - основной компонент в промышленной реализации LSM дерева - merge scheduler, т.е. планировщик слияний и сборки мусора дерева. Я расскажу о подходе, который позволяет максимально снизить износ накопителя, при этом уложиться в заданные рамки производительности запросов.

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