Или как покупать контекстную рекламу в режиме реального времени, и не утонуть в водопаде данных.

1. N☆SQL
Опыт применения NoSQL решений в
проекте Thumbtack RTB Bidder.
Или как покупать контекстную рекламу в режиме
реального времени, и не утонуть в водопаде
данных.
Анатолий Никулин

2. RTB Architecture
Термины:
RTB Exchange (SSP) - биржа,
Bidder (DSP) - брокер
Creative - он же баннер
Publisher - сайт
CPI - Cost per Impression
CPA - Cost per action

3. Real Time Core (Bidder)
За 30 ms надо выбрать пару: Creative + Ставка (Bid)

4. Что принимаем и что отдаем

5. Creative
id: 123123 - идентификатор
size: 120x50 - размер
snippet: "<img src='my-image-adserver.com/1234567'/>"
…
...
index: {
city: [omsk, moskow, spb]
age: [20-25, 30-31]
}
динамические
категории

6. Как хранить креатив в RDBMS?

7. Идеально подходящая
структура - JSON
Где JSON - там и MongoDB :-)
● Динамическая структура
● Гибкий поиск по полям JSON
● Нет проблем с меняющейся схемой, в
процессе разработки.
* MongoDB хранит креативы, кампании, можно делать выборки и отчёты.
Но поиск в режиме реального времени мы ей не доверили. Запилили сами
внутрипроцессный кэш:-) Mongo - не для RT

8. Redis - оперативная статистика
Данных много и обновляются они раз в час
Статистика цен, в разных срезах:
● По дням недели
● По паблишерам
● По времени суток
● По доходности креативов

9. Events
1000 QPS = 86 400 000 в сутки

10. Зачем хранить запросы?
1. История посещений пользователя. По ней можно
вычислить соц. дем. и кое-какие интересы.
rbc.ru
60%
40%
habr.ru
80%
20%

11. Зачем хранить запросы?
2. Referer. &q=”пластиковые окна”
В нем часто можно встретить поисковые запросы,
из которых также можно попытаться достать интересы.

12. Зачем хранить ответы?
Для анализа успешности и эффективности торговой
стратегии.
победа % поражение + цена вопроса

13. Данные льются в HDFS
они не упорядоченны

14. Bulk-load

16. Вопросы?