Your SlideShare is downloading. ×
  • Like
Франкенштейнизация Voldemort или key-value данные в Одноклассниках. Роман Антипин
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Франкенштейнизация Voldemort или key-value данные в Одноклассниках. Роман Антипин

  • 573 views
Published

A talk from jokerconf.com conference. …

A talk from jokerconf.com conference.
"Frankenstaining of Voldemort" or "key-value storage evolution at Odnoklassniki"

В докладе освещены Java-технологии хранения данных, обслуживающие десятки миллионов пользователей и работающие на сотнях серверов.
На примере социальной сети "Одноклассники" мы рассмотрим эволюцию хранилищ данных с высоким уровнем конкурентного доступа и с соблюдением требования постоянной доступности.
Мы разберём сильные и слабые стороны каждого из решений, начиная от технологии master-slave репликации на основе Berkeley DB и заканчивая симбиозом распределенных хранилищ Voldemort и Cassandra.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
573
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
6
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
  • 4. CAP теорема 4
  • 5. Развитие Key-Value хранилищ 5
  • 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
  • 10. Архитектура Voldemort 10
  • 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
  • 28. Спасибо! Контакты http://habrahabr.ru/company/odnoklassniki/blog/ https://github.com/odnoklassniki/ roman.antipin@odnoklassniki.ru http://v.ok.ru