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-only
memcachedb tokyotyrant
+ персистентный + персистетный
+ не ограничен + не ограничен
объёмом ram объёмом ram

7. Варианты
memcache redis
- не персистентный + персистентный
- ram-only - ram-only
memcachedb tokyotyrant
+ персистентный + персистетный
+ не ограничен + не ограничен
объёмом ram объёмом ram

8. Варианты
memcache redis
- не персистентный + персистентный
- ram-only - ram-only
memcachedb 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 1
disk 1
disk 2

14. Перекрёстная репликация
M M
S S

15. M M
S 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 603
Kyoto 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 для профилирования из PHP
https://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.html
8) 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 O'Neil, 1996
http://nosqlsummer.org/paper/lsm-tree
10) btp https://github.com/mambaru/btp-daemon
11) zabbix http://www.zabbix.com/

37. Приложение: Тестирование
производительности: 10M/kyoto
./db_bench_tree_db --benchmarks=fillseq,fillrandom,readrandom,readseq --
num=10000000 --cache_size=536870912
Kyoto Cabinet: version 1.2.76, lib ver 16, lib rev 13
Date: Tue Oct 16 12:12:59 2012
CPU: 8 * Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
CPUCache: 6144 KB
Keys: 16 bytes each
Values: 100 bytes each (50 bytes after compression)
Entries: 10000000
RawSize: 1106.3 MB (estimated)
FileSize: 629.4 MB (estimated)
------------------------------------------------
fillseq : 5.667 micros/op; 19.5 MB/s - 176 460 op/s
fillrandom : 14.995 micros/op; 7.4 MB/s - 66 688 op/s
readrandom : 12.553 micros/op; - 79 662 op/s
readseq : 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=536870912
LevelDB: version 1.6
Date: Tue Oct 16 15:46:23 2012
CPU: 8 * Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
CPUCache: 6144 KB
Keys: 16 bytes each
Values: 100 bytes each (50 bytes after compression)
Entries: 10000000
RawSize: 1106.3 MB (estimated)
FileSize: 629.4 MB (estimated)
------------------------------------------------
fillseq : 2.062 micros/op; 53.6 MB/s - 484 966 op/s
fillrandom : 6.938 micros/op; 15.9 MB/s - 144 133 op/s
readrandom : 11.694 micros/op; - 85 513 op/s
readseq : 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=1073741824
Kyoto Cabinet: version 1.2.76, lib ver 16, lib rev 13
Date: Thu Oct 18 03:37:24 2012
CPU: 8 * Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
CPUCache: 6144 KB
Keys: 16 bytes each
Values: 100 bytes each (50 bytes after compression)
Entries: 100000000
RawSize: 11062.6 MB (estimated)
FileSize: 6294.3 MB (estimated)
------------------------------------------------
fillseq : 56.085 micros/op; 2.0 MB/s - 17 830 op/s
fillrandom : 191.021 micros/op; 0.6 MB/s - 5 235 op/s
readrandom : 93.764 micros/op; - 10 665 op/s
readseq : 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=1
LevelDB: version 1.6
Date: Wed Oct 17 12:52:53 2012
CPU: 8 * Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
CPUCache: 6144 KB
Keys: 16 bytes each
Values: 100 bytes each (50 bytes after compression)
Entries: 100000000
RawSize: 11062.6 MB (estimated)
FileSize: 6294.3 MB (estimated)
------------------------------------------------
fillseq : 2.112 micros/op; 52.4 MB/s - 473 484 op/s
fillrandom : 9.581 micros/op; 11.5 MB/s - 104 373 op/s
readrandom : 65.224 micros/op; - 15 331 op/s
readseq : 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=1073741824
Kyoto Cabinet: version 1.2.76, lib ver 16, lib rev 13
Date: Wed Oct 17 15:39:47 2012
CPU: 8 * Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
CPUCache: 6144 KB
Keys: 16 bytes each
Values: 100 bytes each (50 bytes after compression)
Entries: 100000000
RawSize: 11062.6 MB (estimated)
FileSize: 6294.3 MB (estimated)
------------------------------------------------
fillseq : 40.816 micros/op; 2.7 MB/s - 24 500 op/s
fillrandom : 28.274 micros/op; 3.9 MB/s - 35 368 op/s
readrandom : 35.165 micros/op; - 28 437 op/s
readseq : 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=8
LevelDB: version 1.6
Date: Wed Oct 17 12:06:13 2012
CPU: 8 * Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
CPUCache: 6144 KB
Keys: 16 bytes each
Values: 8 bytes each (4 bytes after compression)
Entries: 100000000
RawSize: 2288.8 MB (estimated)
FileSize: 1907.3 MB (estimated)
------------------------------------------------
fillseq : 1.841 micros/op; 12.4 MB/s - 543 183 op/s
fillrandom : 6.920 micros/op; 3.3 MB/s - 144 508 op/s
readrandom : 16.701 micros/op; - 59 876 op/s
readseq : 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=8
Kyoto Cabinet: version 1.2.76, lib ver 16, lib rev 13
Date: Thu Oct 18 01:28:12 2012
CPU: 8 * Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
CPUCache: 6144 KB
Keys: 16 bytes each
Values: 8 bytes each (4 bytes after compression)
Entries: 100000000
RawSize: 2288.8 MB (estimated)
FileSize: 1907.3 MB (estimated)
------------------------------------------------
fillseq : 30.118 micros/op; 0.8 MB/s - 33 202 op/s
fillrandom : 18.121 micros/op; 1.3 MB/s - 55 184 op/s
readrandom : 28.170 micros/op; - 35 498 op/s
readseq : 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=8
Kyoto Cabinet: version 1.2.76, lib ver 16, lib rev 13
Date: Thu Oct 18 13:34:22 2012
CPU: 8 * Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
CPUCache: 6144 KB
Keys: 16 bytes each
Values: 8 bytes each (4 bytes after compression)
Entries: 100000000
RawSize: 2288.8 MB (estimated)
FileSize: 1907.3 MB (estimated)
------------------------------------------------
fillseq : 7.837 micros/op; 2.9 MB/s - 127 599 op/s
fillrandom : 28.302 micros/op; 0.8 MB/s - 35 333 op/s
readrandom : 25.374 micros/op; - 39 410 op/s
readseq : 1.837 micros/op; 12.5 MB/s - 544 365 op/s

45. Приложение: используемое
железо
CPU: 2 * Xeon 3.0Ghz 6 cores
RAM: 128Gb
HDD: 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)