Доклад был представлен на официальной российской конференции PG Day'14 Russia, посвященной вопросам разработки и эксплуатации PostgreSQL. Социальная сеть является классическим примером продукта, создаваемого людьми, движет которыми желание использовать как можно больше новомодных технологий. О последствиях, естественно, никто не задумывается. К счастью, в нужный момент было принято решение отказаться от части подобных новшеств и использовать старый-добрый PostgreSQL для создания сервиса. Казалось бы, нет ничего хуже, чем реляционная база, для разработки социальной сети? Всем ведь хорошо известно, что типичная стратегия расширения подобного продукта заключается в горизонтальном “шардинге”, денормализации, многоуровневых слоях кеширования и прочих вещах, с которым реляционная СУБД не очень дружит. Тем не менее, в Rubuki.com мы решили пойти наперекор трендам и сделать такую социальную сеть, где используется Rails без ORM, бизнес-логика живет в базе данных, и пользователи каждый день получают корректно отсортированную по дате появления событий новостную ленту (привет, Facebook!). На примере реализации таких компонентов как полнотекстовый поиск, рекомендательный сервис и сервис премирования, я расскажу о нюансах разработки сети, успехах и проблемах, с которыми мы столкнулись.

1. Социальная сеть, которая просто работает

2. В начале
● Нерабочая схема.
● Отсутствие готовой функциональности.
● Жуткие тормоза в базе.
● MySQL.

3. Что делать?
– Нет.

5. Наш ответ

6. ● Рекомендательный сервис
● Система премирования
● Полнотекстовый поиск
Сложные задачи и их решения

7. ● Обновлять рекомендации не реже раза в сутки.
● Минимально возможная нагрузка на сервер.
● Динамичность рекомендаций для каждого пользователя.
● Процент вероятности, что рекомендация близка пользователю.
● Дополнительный расчет рекомендаций, по данным из профиля.
Рекомендательный сервис
Основные требования

8. user B
user C
user D
Rрек = (SUb + SUc + SUd) - SUa; Ecount = 3;
Params from user profile
Books with params
Recommendations
+E
Решение
user A

9. ● Скорость работы в пределах 100мс на
пользователя.
Анализ решения на PostgreSQL
● Возможность распределять выполнение по времени.
● Динамический поиск вхождений.
● Подсчет процента вероятности, с которой
пользователю понравится рекомендация.
● Расчет дополнительных рекомендаций на основе
данных из профиля пользователя.

10. ● Транзакционность.
Система премирования
Основные требования
● Возможность ручного начисления.
● Автономное формирование групповых начислений,
по результатам накопления групп.
● Обновление баланса в режиме реального времени.
● История начислений.
● Распределение нагрузки.

11. Решение на PostgreSQL
SP User action EXT mbus SP Processing
SP withdraw SP deposit
Store
in DB
SP collect groups

12. ● Отказоустойчивость.
● Асинхронная работа (отсутствие нагрузки).
● Легкий рефакторинг логики.
● Повторное использование атомарных операций.
● Реализованы все требования.
Анализ работы решения

13. ● Быстрый поиск данных.
● Возможность масштабирования.
● Ранжирование результатов.
● Поиск по разным критериям.
● Высокая скорость индексации.
Полнотекстовый поиск
Требования

14. Обычно У нас
Противопоставление технологий

15. ● Стабильность решения.
● Возможность масштабирования.
● Приемлемая скорость работы.
● Ожидаемая нагрузка на сервер.
● А почему бы и нет?
Почему PostgreSQL?

16. DB server
MAIN DB
sync
На начальном этапе развития проекта
Схема работы
DATA PREPARED
for search
search request

17. DB server DB server
sync
Как может работать?
При необходимости
Main DB
DATA PREPARED
for search
search request

18. Data prepared
for search
Indexes (gin)
Tsearch2
(full text engine)
Optimized SP
(5 search layers in one)

19. ● Скорость работы.
Плюсы
● Незначительные.
Минусы
● Быстрое внесение изменений.
● Отсутствие неконтролируемого
роста запросов.
● Транзакционность.
● Встроенные решения конкурентного
доступа.
Логика в базе

20. Ваши вопросы?