Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

PG Day'14 Russia, Социальная сеть, которая просто работает, Владислав Коваль

405 views

Published on

Доклад был представлен на официальной российской конференции PG Day'14 Russia, посвященной вопросам разработки и эксплуатации PostgreSQL.

Социальная сеть является классическим примером продукта, создаваемого людьми, движет которыми желание использовать как можно больше новомодных технологий. О последствиях, естественно, никто не задумывается. К счастью, в нужный момент было принято решение отказаться от части подобных новшеств и использовать старый-добрый PostgreSQL для создания сервиса.

Казалось бы, нет ничего хуже, чем реляционная база, для разработки социальной сети? Всем ведь хорошо известно, что типичная стратегия расширения подобного продукта заключается в горизонтальном “шардинге”, денормализации, многоуровневых слоях кеширования и прочих вещах, с которым реляционная СУБД не очень дружит.

Тем не менее, в Rubuki.com мы решили пойти наперекор трендам и сделать такую социальную сеть, где используется Rails без ORM, бизнес-логика живет в базе данных, и пользователи каждый день получают корректно отсортированную по дате появления событий новостную ленту (привет, Facebook!).

На примере реализации таких компонентов как полнотекстовый поиск, рекомендательный сервис и сервис премирования, я расскажу о нюансах разработки сети, успехах и проблемах, с которыми мы столкнулись.

Published in: Software
  • Be the first to comment

PG Day'14 Russia, Социальная сеть, которая просто работает, Владислав Коваль

  1. 1. Социальная сеть, которая просто работает
  2. 2. В начале ● Нерабочая схема. ● Отсутствие готовой функциональности. ● Жуткие тормоза в базе. ● MySQL.
  3. 3. Что делать? – Нет.
  4. 4. Наш ответ
  5. 5. ● Рекомендательный сервис ● Система премирования ● Полнотекстовый поиск Сложные задачи и их решения
  6. 6. ● Обновлять рекомендации не реже раза в сутки. ● Минимально возможная нагрузка на сервер. ● Динамичность рекомендаций для каждого пользователя. ● Процент вероятности, что рекомендация близка пользователю. ● Дополнительный расчет рекомендаций, по данным из профиля. Рекомендательный сервис Основные требования
  7. 7. user B user C user D Rрек = (SUb + SUc + SUd) - SUa; Ecount = 3; Params from user profile Books with params Recommendations +E Решение user A
  8. 8. ● Скорость работы в пределах 100мс на пользователя. Анализ решения на PostgreSQL ● Возможность распределять выполнение по времени. ● Динамический поиск вхождений. ● Подсчет процента вероятности, с которой пользователю понравится рекомендация. ● Расчет дополнительных рекомендаций на основе данных из профиля пользователя.
  9. 9. ● Транзакционность. Система премирования Основные требования ● Возможность ручного начисления. ● Автономное формирование групповых начислений, по результатам накопления групп. ● Обновление баланса в режиме реального времени. ● История начислений. ● Распределение нагрузки.
  10. 10. Решение на PostgreSQL SP User action EXT mbus SP Processing SP withdraw SP deposit Store in DB SP collect groups
  11. 11. ● Отказоустойчивость. ● Асинхронная работа (отсутствие нагрузки). ● Легкий рефакторинг логики. ● Повторное использование атомарных операций. ● Реализованы все требования. Анализ работы решения
  12. 12. ● Быстрый поиск данных. ● Возможность масштабирования. ● Ранжирование результатов. ● Поиск по разным критериям. ● Высокая скорость индексации. Полнотекстовый поиск Требования
  13. 13. Обычно У нас Противопоставление технологий
  14. 14. ● Стабильность решения. ● Возможность масштабирования. ● Приемлемая скорость работы. ● Ожидаемая нагрузка на сервер. ● А почему бы и нет? Почему PostgreSQL?
  15. 15. DB server MAIN DB sync На начальном этапе развития проекта Схема работы DATA PREPARED for search search request
  16. 16. DB server DB server sync Как может работать? При необходимости Main DB DATA PREPARED for search search request
  17. 17. Data prepared for search Indexes (gin) Tsearch2 (full text engine) Optimized SP (5 search layers in one)
  18. 18. ● Скорость работы. Плюсы ● Незначительные. Минусы ● Быстрое внесение изменений. ● Отсутствие неконтролируемого роста запросов. ● Транзакционность. ● Встроенные решения конкурентного доступа. Логика в базе
  19. 19. Ваши вопросы?

×