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
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
17. Выбор нового NoSQL решения
- MongoDB
- CouchDB
- Cassandra - KyotoTycoon
- HBase
- HyperTable
18. KyotoTycoon
Основные отличия от TokyoTyrant:
- Консистентность данных при падении
- Выше скорость
- Меньшие накладные расходы на объём
- HTTP протокол вместо MEMCACHE
- Расширенный интерфейс (HTTP), свои
функции, lua скрипты, плагины
23. Алгоритмы
SSTable: Sorted String Table
возможности:
- быстрое последовательное чтение
- быстрое случайное чтение при
использовании индекса
Index
key1 offset1
key2 offset2
...
24. SSTable: Sorted String Table
- Для быстрой записи используются SSTable
в оперативной памяти (назовём их
MemTable)
- При чтении сначала проверяются индексы
MemTable, а затем SSTable
26. Тестовые данные
- 100M записей - объём базы
- 100 байт - размер одной записи
- 11 Гб - размер несжатых данных
- 6.3 Гб - размер сжатых данных
- 1 Гб - размер кеша
- 16% - cache hit при случайном чтении
28. Сетевой демон LevelDB
Что было реализовано
- сетевое взаимодействие через tcp по
протоколу json-rpc с поддержкой
асинхронных запросов
- репликация мастер-слейв
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)