Embed Size (px)
DESCRIPTION
Доклад был представлен на официальной российской конференции PG Day'14 Russia, посвященной вопросам разработки и эксплуатации PostgreSQL. Социальная сеть является классическим примером продукта, создаваемого людьми, движет которыми желание использовать как можно больше новомодных технологий. О последствиях, естественно, никто не задумывается. К счастью, в нужный момент было принято решение отказаться от части подобных новшеств и использовать старый-добрый PostgreSQL для создания сервиса. Казалось бы, нет ничего хуже, чем реляционная база, для разработки социальной сети? Всем ведь хорошо известно, что типичная стратегия расширения подобного продукта заключается в горизонтальном “шардинге”, денормализации, многоуровневых слоях кеширования и прочих вещах, с которым реляционная СУБД не очень дружит. Тем не менее, в Rubuki.com мы решили пойти наперекор трендам и сделать такую социальную сеть, где используется Rails без ORM, бизнес-логика живет в базе данных, и пользователи каждый день получают корректно отсортированную по дате появления событий новостную ленту (привет, Facebook!). На примере реализации таких компонентов как полнотекстовый поиск, рекомендательный сервис и сервис премирования, я расскажу о нюансах разработки сети, успехах и проблемах, с которыми мы столкнулись.
Citation preview
Социальная сеть, которая просто работает
В начале
● Нерабочая схема.
● Отсутствие готовой функциональности.
● Жуткие тормоза в базе.
● MySQL.
Что делать?
– Нет.
Наш ответ
● Рекомендательный сервис
● Система премирования
● Полнотекстовый поиск
Сложные задачи и их решения
● Обновлять рекомендации не реже раза в сутки.
● Минимально возможная нагрузка на сервер.
● Динамичность рекомендаций для каждого пользователя.
● Процент вероятности, что рекомендация близка пользователю.
● Дополнительный расчет рекомендаций, по данным из профиля.
Рекомендательный сервисОсновные требования
user B
user C
user D
Rрек = (SUb + SUc + SUd) - SUa; Ecount = 3;
Params from user profile
Books with params
Recommendations
+E
Решение
user A
● Скорость работы в пределах 100мс на пользователя.
Анализ решения на PostgreSQL
● Возможность распределять выполнение по времени.
● Динамический поиск вхождений.
● Подсчет процента вероятности, с которой пользователю понравится рекомендация.
● Расчет дополнительных рекомендаций на основе данных из профиля пользователя.
● Транзакционность.
Система премированияОсновные требования
● Возможность ручного начисления.
● Автономное формирование групповых начислений, по результатам накопления групп.
● Обновление баланса в режиме реального времени.
● История начислений.
● Распределение нагрузки.
Решение на PostgreSQL
SP User action EXT mbus SP Processing
SP withdraw SP deposit
Store in DB
SP collect groups
● Отказоустойчивость.
● Асинхронная работа (отсутствие нагрузки).
● Легкий рефакторинг логики.
● Повторное использование атомарных операций.
● Реализованы все требования.
Анализ работы решения
● Быстрый поиск данных.
● Возможность масштабирования.
● Ранжирование результатов.
● Поиск по разным критериям.
● Высокая скорость индексации.
Полнотекстовый поискТребования
Обычно У нас
Противопоставление технологий
● Стабильность решения.
● Возможность масштабирования.
● Приемлемая скорость работы.
● Ожидаемая нагрузка на сервер.
● А почему бы и нет?
Почему PostgreSQL?
DB server
MAIN DBsync
На начальном этапе развития проекта
Схема работы
DATA PREPAREDfor search
search request
DB server DB server
sync
Как может работать?При необходимости
Main DB DATA PREPAREDfor search
search request
Data prepared for search
Indexes (gin) Tsearch2(full text engine)
Optimized SP(5 search layers in one)
● Скорость работы.
Плюсы
● Незначительные.
Минусы
● Быстрое внесение изменений.
● Отсутствие неконтролируемого роста запросов.
● Транзакционность.
● Встроенные решения конкурентного доступа.
Логика в базе
Ваши вопросы?
