1. Как мы храним дружбы.

2. Что такое «дружба» и зачем она нужна.

3. Требования заказчика:
• Ребер → 109
• Вершин → 5 · 107
• Соединений → 2000 – 5000
• Запросов → 12000 – 20000 в сек.
• Обновлений → 200 – 1000 в сек.
• Данных на ребре → 6 байт

4. Типы запросов:
• Высокой актуальности:
– Мои друзья (прямые связи)
– Обратные связи
• Средней актуальности:
– Общие друзья
– Друзья моих друзей
– Я знаком с Васей через Петю и Машу

5. Граф в реляционной базе
Таблица смежности
Вася Петя Дружит 30 байт заголовка
Маша Костю Дружит 14 байт данных
Катя Дашу Ненавидит 80 байт с индексами
– Сложность поиска пути
– Сложности с друзьями друзей

6. Что можно предпринять?
• Упаковать данные Вася
– Фрагментация Катя
– Сложно писать запросы Маша
• Кеширование
– Построчно – бессмысленно
– Запросы целиком – сложно инвалидировать

7. Наш ответ
• Не надо изобретать велосипеды.
– slab аллокатор , сетевое ядро из memcached
– khash.h
– libev
• Чем проще – тем надежнее.
– Простота устройства – легкость
сопровождения.

8. In memory storage
hash slabs buffers
A 1GB
B
C 22GB
1GB
∑ = 24GB

9. Сетевая подсистема
• fork() — невозможно
• -lpthread — сложно разрабатывать и
отлаживать
• FSM
– решение проблемы 10k
– сложно с обрабатывать вычислительные запросы
– запись на диск – отдельным процессом

10. Persistance
T0 T1
T2
– snapshot
– WAL
– Надежное чтение – CRC32

11. Persistance
parent fork child
req writer HDD

12. Hot standby
– bind() – может быть только один
– Пока не можем bind() – проигрываем все
новое и отвечаем на запросы
– Начальный load balancing
A port B

13. Резервное копирование и репликация
• Новые данные на диск пишутся только в
режиме O_APPEND → rsync!
• WAL log player
• Реплики только для чтения
– direct
– light

14. Спасибо за внимание. Вопросы?