Практика использования       NoSQL в высоконагруженном       проекте     Ананьев Дмитрий         "Мамба"
Необходимость в     NoSQL
MessengerСервис для ведения личной переписки- MySQL- 45 серверов (шардинг)- 15 000 req/s- 350 req/s на один сервер в прайм...
Messenger - счётчики сообщений- 27% запросов к MySQL - это счётчики- При каждой отправке/прочтениисообщений- Простые запро...
Messenger - профиль нагрузкиБольшой объём данных, но востребованныев конкретный момент данные составляютлишь малую часть.-...
Вариантыmemcache             redis- не персистентный   + персистентный- ram-only           - ram-onlymemcachedb           ...
Вариантыmemcache             redis- не персистентный   + персистентный- ram-only           - ram-onlymemcachedb           ...
Вариантыmemcache             redis- не персистентный   + персистентный- ram-only           - ram-onlymemcachedb           ...
Тестирование - Brutis- простой- гибкий- много настроек- написан на PHP
Brutis - как тестировали- 30 серверов- 30 потоков на сервер- 30 минутРасчётная нагрузка (пример)   - 4 500 get/s   - 1 600...
Результаты тестирования- memcachedb     - при частой записи сильно нагружал   диск во время синка, в эти моменты его   ско...
Перекрёстная репликация            Sharding     M                    M     S                    S             Backup
RAID 1disk 1disk 2
Перекрёстная репликация M                 M S                 S
M   MS   S
Необходимость в новом       NoSQL
Выбор нового NoSQL решения - MongoDB - CouchDB - Cassandra    - KyotoTycoon - HBase - HyperTable
KyotoTycoonОсновные отличия от TokyoTyrant:  - Консистентность данных при падении  - Выше скорость  - Меньшие накладные ра...
Результаты тестов (random r/w)1 000 000 значений   - 150 000 записей/сек   - 250 000 чтений/сек1 000 000 000 значений   - ...
Последовательная запись- при попытке записать 30 000 000 значений,производительность упала до 250 op/s
LevelDb
Алгоритмы1. SSTable: Sorted String Table File   key1   value1   key2   value2   ...Особенности  - ключи отсортированы  - н...
АлгоритмыSSTable: Sorted String Tableвозможности:  - быстрое последовательное чтение  - быстрое случайное чтение приисполь...
SSTable: Sorted String Table- Для быстрой записи используются SSTableв оперативной памяти (назовём ихMemTable)- При чтении...
Алгоритмы: LSM-tree
Тестовые данные- 100M записей - объём базы- 100 байт - размер одной записи- 11 Гб - размер несжатых данных- 6.3 Гб - разме...
Результаты тестирования на 100МKyoto Tree     5 235   10 665    17 830      65 603Kyoto Hash    35 368   28 437    24 500 ...
Сетевой демон LevelDBЧто было реализовано  - сетевое взаимодействие через tcp попротоколу json-rpc с поддержкойасинхронных...
Сетевой демон LevelDBДополнительный функционал  - inc_add  - update_packed  - get_range (по-умолчанию идут на slave)
РезультатыЗапросы:  - 4700 get/s (0.6ms)  - 1600 update_packed/s (0.8ms)  - 500 inc_add/s (0.7ms)Размер базы:  200 000 000...
LevelDB: среднее время ответа вовремя слияния поддеревьев    GET запросы, от 0.5 мс до 1.4 мс
Утилизация диска во времяслияния поддеревьевПоднимается до 25% (раз в 10 минут) ипродолжается в течение 5 минут
Мониторинг- Zabbix для железа- BTP для профилирования из PHPhttps://github.com/mambaru/btp-daemon
Итоги    MySQL      Tokyo    Memcache   Tyrant     Kyoto     Level    Tycoon     DB
Спасибо за внимание!                        Ананьев                        ДмитрийКомпания «Мамба»   ananyev@mamba.ru
4. Ссылки на используемыерешения1) memcachedb                http://memcachedb.org/2) tokyotyrant               http://fal...
Приложение: Тестированиепроизводительности: 10M/kyoto./db_bench_tree_db --benchmarks=fillseq,fillrandom,readrandom,readseq...
Приложение: Тестированиепроизводительности: 10M/leveldb./db_bench --benchmarks=fillseq,fillrandom,readrandom,readseq --num...
Приложение: Тестированиепроизводительности: 100M/kyoto./db_bench_tree_db --benchmarks=fillseq,fillrandom,readrandom,readse...
Приложение: Тестированиепроизводительности: 100M/leveldb./db_bench --benchmarks=fillseq,fillrandom,readrandom,readseq --nu...
Приложение: Тестированиепроизводительности: 100M/kch./db_bench_hash_db --benchmarks=fillseq,fillrandom,readrandom,readseq ...
Приложение: Тестированиепроизводительности: 100M-8b/ldb./db_bench --benchmarks=fillseq,fillrandom,readrandom,readseq --num...
Приложение: Тестированиепроизводительности: 100M-8b/kch./db_bench_hash_db --benchmarks=fillseq,fillrandom,readrandom,reads...
Приложение: Тестированиепроизводительности: 100M-8b/kct./db_bench_tree_db --benchmarks=fillseq,fillrandom,readrandom,reads...
Приложение: используемоежелезоCPU: 2 * Xeon 3.0Ghz 6 coresRAM: 128GbHDD: RAID1 SAS (15Krpm) 300Gb
Приложние: оптимизацияTokyoTyrant под высокую нагрузкуПараметры запуска TokyoTyrant  - поддержка файлов больше 4 Гб (opts=...
Приложние: оптимизация Kyoto-Tycoon под высокую нагрузку- Число потоков = число ядер - 1 (-th 11)- Hash table (*.kch)- Под...
Приложние: Оптимизация LevelDBпод высокую нагрузкуПараметры оптимизации под высокуюнагрузку:- число открытых файлов: 9 785...
Upcoming SlideShare
Loading in …5
×

Практика использования NoSQL в высоконагруженном проекте (Дмитрий Ананьев)

3,948 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,948
On SlideShare
0
From Embeds
0
Number of Embeds
2,095
Actions
Shares
0
Downloads
26
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Практика использования NoSQL в высоконагруженном проекте (Дмитрий Ананьев)

  1. 1. Практика использования NoSQL в высоконагруженном проекте Ананьев Дмитрий "Мамба"
  2. 2. Необходимость в NoSQL
  3. 3. MessengerСервис для ведения личной переписки- MySQL- 45 серверов (шардинг)- 15 000 req/s- 350 req/s на один сервер в праймтайм
  4. 4. Messenger - счётчики сообщений- 27% запросов к MySQL - это счётчики- При каждой отправке/прочтениисообщений- Простые запросы: 1) UPDATE folder SET messages = messages + 1, unread = unread + 1 WHERE id = 4321; 2) SELECT * FROM folder WHERE id = 4321;
  5. 5. Messenger - профиль нагрузкиБольшой объём данных, но востребованныев конкретный момент данные составляютлишь малую часть.- 18 000 000 пользователей- 150 000 онлайн- 700 сообщений/сек- В основном общаются только с онлайнпользователями
  6. 6. Вариантыmemcache redis- не персистентный + персистентный- ram-only - ram-onlymemcachedb tokyotyrant+ персистентный + персистетный+ не ограничен + не ограниченобъёмом ram объёмом ram
  7. 7. Вариантыmemcache redis- не персистентный + персистентный- ram-only - ram-onlymemcachedb tokyotyrant+ персистентный + персистетный+ не ограничен + не ограниченобъёмом ram объёмом ram
  8. 8. Вариантыmemcache redis- не персистентный + персистентный- ram-only - ram-onlymemcachedb tokyotyrant+ персистентный + персистетный+ не ограничен + не ограниченобъёмом ram объёмом ram
  9. 9. Тестирование - Brutis- простой- гибкий- много настроек- написан на PHP
  10. 10. Brutis - как тестировали- 30 серверов- 30 потоков на сервер- 30 минутРасчётная нагрузка (пример) - 4 500 get/s - 1 600 inc/s - 200 байт - размер каждой записи - 90 000 000 записей
  11. 11. Результаты тестирования- memcachedb - при частой записи сильно нагружал диск во время синка, в эти моменты его скорость снижалась в 100 раз- tokyotyrant - 10 000 get/s - 5 000 set/s
  12. 12. Перекрёстная репликация Sharding M M S S Backup
  13. 13. RAID 1disk 1disk 2
  14. 14. Перекрёстная репликация M M S S
  15. 15. M MS S
  16. 16. Необходимость в новом NoSQL
  17. 17. Выбор нового NoSQL решения - MongoDB - CouchDB - Cassandra - KyotoTycoon - HBase - HyperTable
  18. 18. KyotoTycoonОсновные отличия от TokyoTyrant: - Консистентность данных при падении - Выше скорость - Меньшие накладные расходы на объём - HTTP протокол вместо MEMCACHE - Расширенный интерфейс (HTTP), своифункции, lua скрипты, плагины
  19. 19. Результаты тестов (random r/w)1 000 000 значений - 150 000 записей/сек - 250 000 чтений/сек1 000 000 000 значений - 15 000 записей/сек - 25 000 чтений/сек
  20. 20. Последовательная запись- при попытке записать 30 000 000 значений,производительность упала до 250 op/s
  21. 21. LevelDb
  22. 22. Алгоритмы1. SSTable: Sorted String Table File key1 value1 key2 value2 ...Особенности - ключи отсортированы - неизменяемые файлы
  23. 23. АлгоритмыSSTable: Sorted String Tableвозможности: - быстрое последовательное чтение - быстрое случайное чтение прииспользовании индексаIndex key1 offset1 key2 offset2 ...
  24. 24. SSTable: Sorted String Table- Для быстрой записи используются SSTableв оперативной памяти (назовём ихMemTable)- При чтении сначала проверяются индексыMemTable, а затем SSTable
  25. 25. Алгоритмы: LSM-tree
  26. 26. Тестовые данные- 100M записей - объём базы- 100 байт - размер одной записи- 11 Гб - размер несжатых данных- 6.3 Гб - размер сжатых данных- 1 Гб - размер кеша- 16% - cache hit при случайном чтении
  27. 27. Результаты тестирования на 100МKyoto Tree 5 235 10 665 17 830 65 603Kyoto Hash 35 368 28 437 24 500 668 896 LevelDB 104 373 15 331 473 484 2 652 519
  28. 28. Сетевой демон LevelDBЧто было реализовано - сетевое взаимодействие через tcp попротоколу json-rpc с поддержкойасинхронных запросов - репликация мастер-слейв
  29. 29. Сетевой демон LevelDBДополнительный функционал - inc_add - update_packed - get_range (по-умолчанию идут на slave)
  30. 30. РезультатыЗапросы: - 4700 get/s (0.6ms) - 1600 update_packed/s (0.8ms) - 500 inc_add/s (0.7ms)Размер базы: 200 000 000 записей - в production. (2 000 000 000 - тестируется).
  31. 31. LevelDB: среднее время ответа вовремя слияния поддеревьев GET запросы, от 0.5 мс до 1.4 мс
  32. 32. Утилизация диска во времяслияния поддеревьевПоднимается до 25% (раз в 10 минут) ипродолжается в течение 5 минут
  33. 33. Мониторинг- Zabbix для железа- BTP для профилирования из PHPhttps://github.com/mambaru/btp-daemon
  34. 34. Итоги MySQL Tokyo Memcache Tyrant Kyoto Level Tycoon DB
  35. 35. Спасибо за внимание! Ананьев ДмитрийКомпания «Мамба» ananyev@mamba.ru
  36. 36. 4. Ссылки на используемыерешения1) memcachedb http://memcachedb.org/2) tokyotyrant http://fallabs.com/tokyotyrant/3) brutis http://code.google.com/p/brutis/4) kyototycoon http://fallabs.com/kyototycoon/5) kyotocabinet http://fallabs.com/kyotocabinet/6) leveldb project http://code.google.com/p/leveldb/7) leveldb benchmarks http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html8) SSTable and Log Structured Storage: LevelDB by Ilya Grigorik, 2012 http://www.igvita.com/2012/02/06/sstable-and-log-structured-storage-leveldb/9) The Log-Structured Merge-Tree (LSM-Tree) by Patrick ONeil, 1996 http://nosqlsummer.org/paper/lsm-tree10) btp https://github.com/mambaru/btp-daemon11) zabbix http://www.zabbix.com/
  37. 37. Приложение: Тестированиепроизводительности: 10M/kyoto./db_bench_tree_db --benchmarks=fillseq,fillrandom,readrandom,readseq --num=10000000 --cache_size=536870912Kyoto Cabinet: version 1.2.76, lib ver 16, lib rev 13Date: Tue Oct 16 12:12:59 2012CPU: 8 * Intel(R) Xeon(R) CPU E5450 @ 3.00GHzCPUCache: 6144 KBKeys: 16 bytes eachValues: 100 bytes each (50 bytes after compression)Entries: 10000000RawSize: 1106.3 MB (estimated)FileSize: 629.4 MB (estimated)------------------------------------------------fillseq : 5.667 micros/op; 19.5 MB/s - 176 460 op/sfillrandom : 14.995 micros/op; 7.4 MB/s - 66 688 op/sreadrandom : 12.553 micros/op; - 79 662 op/sreadseq : 2.527 micros/op; 43.8 MB/s - 395 726 op/s
  38. 38. Приложение: Тестированиепроизводительности: 10M/leveldb./db_bench --benchmarks=fillseq,fillrandom,readrandom,readseq --num=10000000 --bloom_bits=16 --write_buffer_size=536870912 --cache_size=536870912LevelDB: version 1.6Date: Tue Oct 16 15:46:23 2012CPU: 8 * Intel(R) Xeon(R) CPU E5450 @ 3.00GHzCPUCache: 6144 KBKeys: 16 bytes eachValues: 100 bytes each (50 bytes after compression)Entries: 10000000RawSize: 1106.3 MB (estimated)FileSize: 629.4 MB (estimated)------------------------------------------------fillseq : 2.062 micros/op; 53.6 MB/s - 484 966 op/sfillrandom : 6.938 micros/op; 15.9 MB/s - 144 133 op/sreadrandom : 11.694 micros/op; - 85 513 op/sreadseq : 0.460 micros/op; 240.7 MB/s - 2 173 913 op/s
  39. 39. Приложение: Тестированиепроизводительности: 100M/kyoto./db_bench_tree_db --benchmarks=fillseq,fillrandom,readrandom,readseq --num=100000000 --cache_size=1073741824Kyoto Cabinet: version 1.2.76, lib ver 16, lib rev 13Date: Thu Oct 18 03:37:24 2012CPU: 8 * Intel(R) Xeon(R) CPU E5450 @ 3.00GHzCPUCache: 6144 KBKeys: 16 bytes eachValues: 100 bytes each (50 bytes after compression)Entries: 100000000RawSize: 11062.6 MB (estimated)FileSize: 6294.3 MB (estimated)------------------------------------------------fillseq : 56.085 micros/op; 2.0 MB/s - 17 830 op/sfillrandom : 191.021 micros/op; 0.6 MB/s - 5 235 op/sreadrandom : 93.764 micros/op; - 10 665 op/sreadseq : 15.243 micros/op; 7.3 MB/s - 65 603 op/s
  40. 40. Приложение: Тестированиепроизводительности: 100M/leveldb./db_bench --benchmarks=fillseq,fillrandom,readrandom,readseq --num=100000000 --bloom_bits=16 --write_buffer_size=536870912 --cache_size=536870912 --threads=1LevelDB: version 1.6Date: Wed Oct 17 12:52:53 2012CPU: 8 * Intel(R) Xeon(R) CPU E5450 @ 3.00GHzCPUCache: 6144 KBKeys: 16 bytes eachValues: 100 bytes each (50 bytes after compression)Entries: 100000000RawSize: 11062.6 MB (estimated)FileSize: 6294.3 MB (estimated)------------------------------------------------fillseq : 2.112 micros/op; 52.4 MB/s - 473 484 op/sfillrandom : 9.581 micros/op; 11.5 MB/s - 104 373 op/sreadrandom : 65.224 micros/op; - 15 331 op/sreadseq : 0.377 micros/op; 293.5 MB/s - 2 652 519 op/s
  41. 41. Приложение: Тестированиепроизводительности: 100M/kch./db_bench_hash_db --benchmarks=fillseq,fillrandom,readrandom,readseq --num=100000000 --cache_size=1073741824Kyoto Cabinet: version 1.2.76, lib ver 16, lib rev 13Date: Wed Oct 17 15:39:47 2012CPU: 8 * Intel(R) Xeon(R) CPU E5450 @ 3.00GHzCPUCache: 6144 KBKeys: 16 bytes eachValues: 100 bytes each (50 bytes after compression)Entries: 100000000RawSize: 11062.6 MB (estimated)FileSize: 6294.3 MB (estimated)------------------------------------------------fillseq : 40.816 micros/op; 2.7 MB/s - 24 500 op/sfillrandom : 28.274 micros/op; 3.9 MB/s - 35 368 op/sreadrandom : 35.165 micros/op; - 28 437 op/sreadseq : 1.495 micros/op; 74.0 MB/s - 668 896 op/s
  42. 42. Приложение: Тестированиепроизводительности: 100M-8b/ldb./db_bench --benchmarks=fillseq,fillrandom,readrandom,readseq --num=100000000 --bloom_bits=16 --write_buffer_size=536870912 --cache_size=536870912 --threads=1 --value_size=8LevelDB: version 1.6Date: Wed Oct 17 12:06:13 2012CPU: 8 * Intel(R) Xeon(R) CPU E5450 @ 3.00GHzCPUCache: 6144 KBKeys: 16 bytes eachValues: 8 bytes each (4 bytes after compression)Entries: 100000000RawSize: 2288.8 MB (estimated)FileSize: 1907.3 MB (estimated)------------------------------------------------fillseq : 1.841 micros/op; 12.4 MB/s - 543 183 op/sfillrandom : 6.920 micros/op; 3.3 MB/s - 144 508 op/sreadrandom : 16.701 micros/op; - 59 876 op/sreadseq : 0.257 micros/op; 89.1 MB/s - 3 891 050 op/s
  43. 43. Приложение: Тестированиепроизводительности: 100M-8b/kch./db_bench_hash_db --benchmarks=fillseq,fillrandom,readrandom,readseq --num=100000000 --cache_size=1073741824 --value_size=8Kyoto Cabinet: version 1.2.76, lib ver 16, lib rev 13Date: Thu Oct 18 01:28:12 2012CPU: 8 * Intel(R) Xeon(R) CPU E5450 @ 3.00GHzCPUCache: 6144 KBKeys: 16 bytes eachValues: 8 bytes each (4 bytes after compression)Entries: 100000000RawSize: 2288.8 MB (estimated)FileSize: 1907.3 MB (estimated)------------------------------------------------fillseq : 30.118 micros/op; 0.8 MB/s - 33 202 op/sfillrandom : 18.121 micros/op; 1.3 MB/s - 55 184 op/sreadrandom : 28.170 micros/op; - 35 498 op/sreadseq : 0.777 micros/op; 29.5 MB/s - 1 287 001 op/s
  44. 44. Приложение: Тестированиепроизводительности: 100M-8b/kct./db_bench_tree_db --benchmarks=fillseq,fillrandom,readrandom,readseq --num=100000000 --cache_size=1073741824 --value_size=8Kyoto Cabinet: version 1.2.76, lib ver 16, lib rev 13Date: Thu Oct 18 13:34:22 2012CPU: 8 * Intel(R) Xeon(R) CPU E5450 @ 3.00GHzCPUCache: 6144 KBKeys: 16 bytes eachValues: 8 bytes each (4 bytes after compression)Entries: 100000000RawSize: 2288.8 MB (estimated)FileSize: 1907.3 MB (estimated)------------------------------------------------fillseq : 7.837 micros/op; 2.9 MB/s - 127 599 op/sfillrandom : 28.302 micros/op; 0.8 MB/s - 35 333 op/sreadrandom : 25.374 micros/op; - 39 410 op/sreadseq : 1.837 micros/op; 12.5 MB/s - 544 365 op/s
  45. 45. Приложение: используемоежелезоCPU: 2 * Xeon 3.0Ghz 6 coresRAM: 128GbHDD: RAID1 SAS (15Krpm) 300Gb
  46. 46. Приложние: оптимизацияTokyoTyrant под высокую нагрузкуПараметры запуска TokyoTyrant - поддержка файлов больше 4 Гб (opts=l) - dbtype = hash table (*.tch) - hash подходит для простого key/value - быстрее, чем btree (*.tcb) - включена асинхронная запись на диск
  47. 47. Приложние: оптимизация Kyoto-Tycoon под высокую нагрузку- Число потоков = число ядер - 1 (-th 11)- Hash table (*.kch)- Поддержка файлов больше 4 Гб (#opts=l)- Количество значений (#bnum=1000000000)- Кеш в ОЗУ (#msiz=10g)
  48. 48. Приложние: Оптимизация LevelDBпод высокую нагрузкуПараметры оптимизации под высокуюнагрузку:- число открытых файлов: 9 785 419 (fs.file-max = 9785419)- количество потоков:10 (--threads_tcp=10)- размер буфера записи: 128Мб (--buffer=128)- размер кеша: 40Гб (--memory=40960)

×