Франкенштейнизация Voldemort или key-value данные в Одноклассниках. Роман Антипин
•
1 like•1,599 views
A talk from jokerconf.com conference. "Frankenstaining of Voldemort" or "key-value storage evolution at Odnoklassniki" В докладе освещены Java-технологии хранения данных, обслуживающие десятки миллионов пользователей и работающие на сотнях серверов. На примере социальной сети "Одноклассники" мы рассмотрим эволюцию хранилищ данных с высоким уровнем конкурентного доступа и с соблюдением требования постоянной доступности. Мы разберём сильные и слабые стороны каждого из решений, начиная от технологии master-slave репликации на основе Berkeley DB и заканчивая симбиозом распределенных хранилищ Voldemort и Cassandra.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Франкенштейнизация Voldemort или key-value данные в Одноклассниках. Роман Антипин
Similar to Франкенштейнизация Voldemort или key-value данные в Одноклассниках. Роман Антипин (20)
More from odnoklassniki.ru
More from odnoklassniki.ru (8)
Франкенштейнизация Voldemort или key-value данные в Одноклассниках. Роман Антипин
- 1. Франкенштейнизация Voldemort или key-value данные в Одноклассниках Роман Антипин инженер-программист проекта Одноклассники
- 2. 2
- 3. Данные в Одноклассниках • • • • • SQL (MSSQL): ~ 330 серверов без учета backup, ~28 TB Blob storage (OBS): ~ 460 серверов, ~1.5 PB Column Family (Cassandra): ~ 410 серверов, ~70 TB Key-Value (Voldemort): ~ 220 серверов, ~2.2 TB Key-Value, Queue (Berkeley DB): ~100 серверов, ~1 TB 3 года назад: • SQL (MSSQL) • Key-Value, Queue (Berkeley DB) 3
- 6. Решение на основе Berkley DB 6
- 7. Недостатки решения с Berkley DB • • • • • Низкая отказоустойчивость (data corruption) Ограничение в масштабируемости Сложное обслуживание (ручная работа по восстановлению) Высокая стоимость (много update => slave == backup) Berkley DB 4.5 (Си) необходимо использовать JNI – Пробовали Berkley DB 5.0 (Си) – снижение производительности 7
- 8. Требования к key-value хранилищу. Итерация 1 • • • • • • Open source Высокая доступность, отказоустойчивость (data corruption) Неограниченная масштабируемость без down time Высокая производительность для отношения 3:R / 1:W Возможность использования дешевого железа Простота обслуживания (минимум ручной работы, только для восстановления персистентных отказов оборудования) 8
- 9. Анализ существующих решений (2010 г.) • Cassandra 0.6.4 – – – – Column Family Поддерживает Hinted Handoff и Read-repair Java Нет механизма определения конфликтов (timestamp) • Voldemort 0.8.1 – – – – – Pluggable backend (default Berkley DB) Поддерживает Read-repair Механизм определения конфликтов (Vector Clock) Java Отсутствие Hinted Handoff • Riak – Сопоставим с Voldemort – Erlang 9
- 11. Vector clock 11
- 12. Tarantool как back end для Voldemort • In-Memory NoSQL database – Высокая производительность без деградации – Ограничение по RAM • • • • • • • Персистентность за счет commit logs и snapshots Поддержка вторичных индексов Поддержка хранимых процедур на lua Опыт использования в @mail.ru Кооперативная многозадачность Отсутствие embedded решения Максимальный размер кортежа 1Мб 12
- 13. Исследование производительности Тесты для кластера 3 ноды с replication factor 3, read/write quorum 2 Сервера SuperMicro 2 CPU(8 cores), RAM 32 Gb, 500 Gb SATA 7200. Размер данных ~1-5Kb, объем данных 25Gb, read 50%, write 50% • Voldemort 0.8.1 (BerkeleyDB java edition) – Read: ~32K req/sec – Write: ~7.5K req/sec • Voldemort 0.8.1 (Tarantool) – Read: ~36K req/sec – Write: ~9K req/sec 13
- 14. Результаты использования Voldemort+Tarantool • • • • • Нет повреждений данных (data corruption) Высокая доступность (устойчивость к падению любой ноды) Масштабируемость без down time Время старта кластера ~20 минут (объем ноды ~80G) Необходимость ручной работы только в случае полного восстановления ноды или расширения кластера • Увеличение пропускной способности (throughput) в ~2 раза • Увеличение среднего времени операций (latency) на ~50% • Наличие небольшого количества повторных изменений 14
- 15. Примеры использования Всего на данный момент запущено 25 кластеров Service Servers Calls / calls per node, ops Average request time Average data size Cluster size Instantmessenger 24 600k / 26k 1.3ms 1.5kb 224G Suggested 12 140k / 11k 1.5ms 22kb 584G Black list 12 400k / 33k 1.1ms 0.6kb 20G Music playlist 9 37k / 4k 0.9ms 1.4kb 90G P.S: ping local DC ~150µs , cross DC ~500µs 15
- 16. Графики на примере сервиса сообщений 16
- 17. Требования к key-value хранилищу. Итерация 2 • • • • • Избавиться от In-Memory ограничения Увеличение производительности Простая миграция на новое хранилище Embedded storage engine Желательно pure Java 17
- 18. Анализ решений на замену Tarantool • Kyoto Cabinet 1.2.76 – Key-Value – Различные типы storage (HashDB, TreeDB, …) – C++ • LevelDB 1.9.0 – Key-Value – Использует LSM Tree и SSTable – C++ • Cassandra 0.6.4 – Column Family – Использует LSM Tree и SSTable – Java 18
- 19. Тестовая конфигурация • Тестовый сервер – – – – – – Intel Xeon CPU E5506 2.13GHz RAM: 48Gb Linux kernel: 2.6.34 HDD ST3500320NS (7200rpm 32Mb) SSD INTEL SSDSA2CW300G3 File system: xfs rw, noatime, nodiratime, delaylog, noquota • Тестовые данные – 90M записей key – long , value – byte[1000] 19
- 20. Kyoto Cabinet 1.2.76 Параметры: HashDB, opts=TLINEAR, bnum=200M, msiz=30G, dfunit=8 60000 Insert data, 10 threads 50000 rps 40000 30000 20000 10000 0 0 1000 2000 3000 4000 5000 6000 7000 time 20
- 21. LevelDB 1.9.0 50000 Параметры конфигурации: 45000 • • • • • • • 40000 30000 25000 20000 15000 10000 5000 0 0 100 200 300 400 time 500 600 700 800 30000 25000 Параметры теста: • • • • cache hit rate 90% read threads 30 write threads 10 write unlimited 20000 read rps write rps 35000 max_open_files=100K block_size=4000 byte write_buffer_size=512M block_cache=LRUCache(30G) filter_policy=NewBloomFilterPolicy(10) logs - hdd, sstables – ssd, увеличен размер L0 15000 10000 5000 0 0 100 200 300 400 time 500 600 700 21 800
- 22. LevelDB 1.9.0 14000 12000 8000 6000 4000 2000 0 0 50 100 150 time 200 250 300 45000 40000 35000 Параметры теста: • • • • cache hit rate 90% read threads 30 write threads 10 write limit 10K 30000 read rps write rps 10000 25000 20000 15000 10000 5000 0 0 50 100 150 time 200 250 300 22
- 23. Cassandra 0.6.4 90000 Параметры конфигурации: 80000 • • • • • • 70000 50000 40000 30000 20000 10000 0 0 150 300 450 600 750 900 40000 time 35000 Параметры теста: • • • • cache hit rate 90% read threads 30 write threads 10 write unlimited 30000 read rps write rps 60000 RowsCached=15M MemtableThroughputInMB=512 IndexInterval=128 CommitLogRotationThresholdMB=128 DiskAccessMode=mmap logs - hdd, sstables – ssd 25000 20000 15000 10000 5000 0 0 150 300 450 time 600 750 23 900
- 24. Cassandra 0.6.4 25000 15000 10000 5000 0 0 50 100 150 200 250 70000 time 60000 50000 Параметры теста: • • • • cache hit rate 90% read threads 30 write threads 10 write limit 10K read rps write rps 20000 40000 30000 20000 10000 0 0 50 100 150 time 200 250 24
- 25. LSM Tree & SSTable 25
- 26. Интересные факты • Не используем Cassandra cache – Используем ConcurrentLinkedHashMap SECOND_CHANCE – Производительность ConcurrentLinkedHashMap 1.4 LRU < ~50% – В качестве Value MemoryWrapper через sun.misc.Unsafe • Off heap allocation malloc (glibс 2.5) -> tcmalloc – Отсутствие деградации – Average allocation time ~ 800 ns против десятков µs • Тюнинг linux по примеру LVS и HAProxy, снижение average client time на ~30% 26
- 27. Результаты • • • • Снято ограничение In-Memory Embedded java storage Возможность максимально использовать железо Увеличение производительности – – – – Instant-messenger (~1.5 kb данные) с одной ноды ~30K -> ~90K Cache hit rate ~95% Reads ~75K Writes ~15K Сокращение количества серверов с 24 -> 12 • Cleanup без полного обхода, сохраняется информация о tombstone на каждой ноде 27