Your SlideShare is downloading. ×
Практика использования NoSQL в высоконагруженном проекте (Дмитрий Ананьев)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

3,442

Published on

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

No Downloads
Views
Total Views
3,442
On Slideshare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
25
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. Практика использования NoSQL в высоконагруженном проекте Ананьев Дмитрий "Мамба"
  • 2. Необходимость в NoSQL
  • 3. MessengerСервис для ведения личной переписки- MySQL- 45 серверов (шардинг)- 15 000 req/s- 350 req/s на один сервер в праймтайм
  • 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. Messenger - профиль нагрузкиБольшой объём данных, но востребованныев конкретный момент данные составляютлишь малую часть.- 18 000 000 пользователей- 150 000 онлайн- 700 сообщений/сек- В основном общаются только с онлайнпользователями
  • 6. Вариантыmemcache redis- не персистентный + персистентный- ram-only - ram-onlymemcachedb tokyotyrant+ персистентный + персистетный+ не ограничен + не ограниченобъёмом ram объёмом ram
  • 7. Вариантыmemcache redis- не персистентный + персистентный- ram-only - ram-onlymemcachedb tokyotyrant+ персистентный + персистетный+ не ограничен + не ограниченобъёмом ram объёмом ram
  • 8. Вариантыmemcache redis- не персистентный + персистентный- ram-only - ram-onlymemcachedb tokyotyrant+ персистентный + персистетный+ не ограничен + не ограниченобъёмом ram объёмом ram
  • 9. Тестирование - Brutis- простой- гибкий- много настроек- написан на PHP
  • 10. Brutis - как тестировали- 30 серверов- 30 потоков на сервер- 30 минутРасчётная нагрузка (пример) - 4 500 get/s - 1 600 inc/s - 200 байт - размер каждой записи - 90 000 000 записей
  • 11. Результаты тестирования- memcachedb - при частой записи сильно нагружал диск во время синка, в эти моменты его скорость снижалась в 100 раз- tokyotyrant - 10 000 get/s - 5 000 set/s
  • 12. Перекрёстная репликация Sharding M M S S Backup
  • 13. RAID 1disk 1disk 2
  • 14. Перекрёстная репликация M M S S
  • 15. M MS S
  • 16. Необходимость в новом NoSQL
  • 17. Выбор нового NoSQL решения - MongoDB - CouchDB - Cassandra - KyotoTycoon - HBase - HyperTable
  • 18. KyotoTycoonОсновные отличия от TokyoTyrant: - Консистентность данных при падении - Выше скорость - Меньшие накладные расходы на объём - HTTP протокол вместо MEMCACHE - Расширенный интерфейс (HTTP), своифункции, lua скрипты, плагины
  • 19. Результаты тестов (random r/w)1 000 000 значений - 150 000 записей/сек - 250 000 чтений/сек1 000 000 000 значений - 15 000 записей/сек - 25 000 чтений/сек
  • 20. Последовательная запись- при попытке записать 30 000 000 значений,производительность упала до 250 op/s
  • 21. LevelDb
  • 22. Алгоритмы1. SSTable: Sorted String Table File key1 value1 key2 value2 ...Особенности - ключи отсортированы - неизменяемые файлы
  • 23. АлгоритмыSSTable: Sorted String Tableвозможности: - быстрое последовательное чтение - быстрое случайное чтение прииспользовании индексаIndex key1 offset1 key2 offset2 ...
  • 24. SSTable: Sorted String Table- Для быстрой записи используются SSTableв оперативной памяти (назовём ихMemTable)- При чтении сначала проверяются индексыMemTable, а затем SSTable
  • 25. Алгоритмы: LSM-tree
  • 26. Тестовые данные- 100M записей - объём базы- 100 байт - размер одной записи- 11 Гб - размер несжатых данных- 6.3 Гб - размер сжатых данных- 1 Гб - размер кеша- 16% - cache hit при случайном чтении
  • 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. Сетевой демон LevelDBЧто было реализовано - сетевое взаимодействие через tcp попротоколу json-rpc с поддержкойасинхронных запросов - репликация мастер-слейв
  • 29. Сетевой демон LevelDBДополнительный функционал - inc_add - update_packed - get_range (по-умолчанию идут на slave)
  • 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. LevelDB: среднее время ответа вовремя слияния поддеревьев GET запросы, от 0.5 мс до 1.4 мс
  • 32. Утилизация диска во времяслияния поддеревьевПоднимается до 25% (раз в 10 минут) ипродолжается в течение 5 минут
  • 33. Мониторинг- Zabbix для железа- BTP для профилирования из PHPhttps://github.com/mambaru/btp-daemon
  • 34. Итоги MySQL Tokyo Memcache Tyrant Kyoto Level Tycoon DB
  • 35. Спасибо за внимание! Ананьев ДмитрийКомпания «Мамба» ananyev@mamba.ru
  • 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. Приложение: Тестированиепроизводительности: 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. Приложение: Тестированиепроизводительности: 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. Приложение: Тестированиепроизводительности: 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. Приложение: Тестированиепроизводительности: 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. Приложение: Тестированиепроизводительности: 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. Приложение: Тестированиепроизводительности: 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. Приложение: Тестированиепроизводительности: 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. Приложение: Тестированиепроизводительности: 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. Приложение: используемоежелезоCPU: 2 * Xeon 3.0Ghz 6 coresRAM: 128GbHDD: RAID1 SAS (15Krpm) 300Gb
  • 46. Приложние: оптимизацияTokyoTyrant под высокую нагрузкуПараметры запуска TokyoTyrant - поддержка файлов больше 4 Гб (opts=l) - dbtype = hash table (*.tch) - hash подходит для простого key/value - быстрее, чем btree (*.tcb) - включена асинхронная запись на диск
  • 47. Приложние: оптимизация Kyoto-Tycoon под высокую нагрузку- Число потоков = число ядер - 1 (-th 11)- Hash table (*.kch)- Поддержка файлов больше 4 Гб (#opts=l)- Количество значений (#bnum=1000000000)- Кеш в ОЗУ (#msiz=10g)
  • 48. Приложние: Оптимизация LevelDBпод высокую нагрузкуПараметры оптимизации под высокуюнагрузку:- число открытых файлов: 9 785 419 (fs.file-max = 9785419)- количество потоков:10 (--threads_tcp=10)- размер буфера записи: 128Мб (--buffer=128)- размер кеша: 40Гб (--memory=40960)

×