Архитектура поиска в
Booking.com
Иван Круглов

Амстердам

We must deliver the best experience,
as frictionless as possible, and grow
and adapt fast to the customer’s need
by Eduardo Shiota

We must deliver the best experience,
as frictionless as possible, and grow
and adapt fast to the customer’s need
by Eduardo Shiota

by Eduardo Shiota
We must deliver the best experience,
as frictionless as possible, and grow
and adapt fast to the customer’s need

0
200,000
400,000
600,000
800,000
1,000,000
1,200,000
2002 2004 2006 2008 2010 2012 2014 2016
объектов
размещения
ежедневно
забронированных
ночей

by Eduardo Shiota
We must deliver the best experience,
as frictionless as possible, and grow
and adapt fast to the customer’s need

try & fail

A/B
тестирование

Buy now
Buy now
vs

1000+ экспериментов
70+ роллаутов в день

by Eduardo Shiota
We must deliver the best experience,
as frictionless as possible, and grow
and adapt fast to the customer’s need

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

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

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

почему важна
скорость?
https://goo.gl/DP593v
https://goo.gl/HhquKL
https://goo.gl/w1RIhH
https://goo.gl/brL9Zx
https://goo.gl/EbXZl1
https://goo.gl/Gcaunb

поиск
90%
10%
поиск
50%
50%

поиск
эволюция
поиска
текущая архитектура
заключение
План

ПОИСК

поиск
отбор по атрибутам
group fit
отбор по availability
ранжирование
autocomplete
&
disambiguation
определение
геопозиции
деревня Париж, Кигинский район, Республика Башкортостан, Россия ?

inventory
гостиница
«Домик с трубой»
1 янв. 2 янв. 3 янв.
2 000 ₽ 1750 ₽
4 янв. 5 янв.
1500 ₽ 1250 ₽
availability
гостиница
«Домик с трубой»
стоит 6500 ₽
с 1 янв. по 5 янв.

1 янв. 2 янв. 3 янв.
2 000 ₽ 1750 ₽
4 янв. 5 янв.
1500 ₽ 1250 ₽
2 янв. 3 янв. 4 янв. 5 янв.
2 150 ₽ занято 1 650 ₽ 1 150 ₽
1 янв.
2 000 ₽ 1 750 ₽ N/A занято
1 900 ₽ занято занято 900 ₽
занято 1 500 ₽ занято N/A
с звтрк, беспл. отмена
без звтрк, беспл. отмена
с звтрк, плати вперед
без звтрк, плати вперед

Эволюция поиска

< 100 000 (до 2010 г.)
• теплый LAMP-овый стек с 2003 г.
• монолитная архитектура
inv
поиск

~150 000 (около 2010 г.)
• тяжелый расчет availability
• надо: ~500 отелей в Париже
* 3+ типа комнат
* 2+ тарифа
= 3000+ расчетов
• можем:
• 1000 расчетов в сек для 1 ночи
• 90 расчетов в сек для 30 ночей
inv
поиск

Что делать?
1. Кэширование
• max cache hit ratio: 60%
2. Давайте перепишем все на X?
• пострадает agility
• есть что лучше?
3. Можно попробовать материализовать!
• высокий и ровный performance
• огромный объем данных
1 янв. – 2 янв. = 2000 ₽
1 янв. – 3 янв. = 3750 ₽
1 янв. – 4 янв. = 5250 ₽
1 янв. – 5 янв. = 6500 ₽
2 янв. – 3 янв. = 1750 ₽
2 янв. – 4 янв. = 3250 ₽
2 янв. – 5 янв. = 4500 ₽
3 янв. – 4 янв. = 1500 ₽
3 янв. – 5 янв. = 2750 ₽
4 янв. – 5 янв. = 1250 ₽

1 млн. отелей
3+ типа комнат
2+ тарифа
1-30 длительностей проживания
данные на 1+ год вперед
100 млрд.
цен

• как не испортить user experience?
• как поддерживать
консистентность?
Схема с материализацией
поиск
AVinv материализация AVAV

поиск
autocomplete
&
disambiguation
t = минуты

inv
AV
…
global
realtime
queue
global batch
queue
realtime
queue
batch
queue
расчет
нового дня
AV
AV
кластер материализации
материализатор
материализатор
материализатор
материализатор
очередь
уведомлений
источник
обновления

AV БД
• оптимизируем под чтение
• кластеризация PK по геопозиции (Z-order curve)
• шардинг по check-in
• 1x изменение в inv => 1000x изменений в AV
• SSD
• 4K IOPs reads+writes, 45 MB/s
AV
AV
AV
https://goo.gl/24mFR8

• ускорение в 50-100x раз
• быстрый холодный старт
• время материализации
в норме < 1 мин
• метрики + алерты
• quality check
Результаты
поиск
AVinv материализация AVAV

500 000+ (до ~2014 г.)
• uwsgi + nginx + perl + mysql
• рост бизнеса
• новые фичи
• поиск по странам и регионам
• один запрос = один воркер

2014 – 2015 гг.
• Map-Reduce фреймворк
• SOA
• большие запросы – быстрее
• маленькие запросы – медленнее
• IPC overheads
AVinv материализация AVAV
MR
веб-сервер
MR
MR

Текущая архитектура

Надо что-то менять!
• что хотелось:
• отойти от устаревших подходов
• сохранить MR и SOA
• быстрый доступ к AV и другим данным
• база данных в которую можно быстро писать
• дешевый параллелизм
• попробовали Tarantool
• будем делать:
• Perl => Java
• multithreading, меньший константный фактор
• данные in-memory
• MySQL => RocksDB

координатор
координатор
веб-сервер
координатор
AVпоиск AVпоиск AVпоиск
AVпоиск AVпоиск AVпоиск
AVпоиск AVпоиск AVпоиск
статический шардинг
hotel_id mod N
реплики эквивалентны
shard0
реплика0 реплика1 реплика M
…
…
…
shard1
shardN
… … …
материал.
очередь
availability
материализация
inv
scatter-gather
рандомный выбор
реплики
retry, если необходимо
ping nodes
апдейты за
последние часы
in-memory индексы
AV persisted

Paris => [ hotels in Paris ]
has_parking => [ hotels with parking ]
входные данные:
1. геопозиция: Париж
2. атрибуты поиска: парковка, завтрак и т.д.
инвертированные индексы
Paris => [ hotels in Paris ]
has_parking => [ hotels with parking ]
Париж => [ отели в Париже ]
has_parking => [ отели с парковкой ]
отели отели отели
thread 0 thread Nthread 1
…
filter
sort
topn
filter
sort
topn
filter
sort
topn
merge
…
к координатору
AV
входные данные:
3. check-in, check-out
4. состав «команды»

Почему встроенная БД?
Почему именно RocksDB?
Почему RocksDB?
http://rocksdb.org

Почему встроенная БД?
latency в масштабе
CPU цикл 0,3 нс 1 с
доступ в L1 кэш 0,9 нс 3 с
доступ в L2 кэш 2,8 нс 9 с
доступ в L3 кэш 12,9 нс 43 с
доступ в основную память 120 нс 6 мин
сжатие 1КБ в Snappy 3 000 нс 2,7 час
отправка 1КБ по сети 10 000 нс 9 час
чтение 1МБ из основной памяти 250 000 нс 9 дней
round trip внутри датацентра 500 000 нс 19 дней
ретрансмит TCP пакета 2 000 000 000 нс 200 лет
https://gist.github.com/jboner/2841832
http://talks.godoc.org/github.com/davecheney/high-performance-go-workshop/high-performance-go-workshop.slide#1

Почему встроенная БД?
latency в масштабе
CPU цикл 0,3 нс 1 с
доступ в L1 кэш 0,9 нс 3 с
доступ в L2 кэш 2,8 нс 9 с
доступ в L3 кэш 12,9 нс 43 с
доступ в основную память 120 нс 6 мин
сжатие 1КБ в Snappy 3 000 нс 2,7 час
отправка 1КБ по сети 10 000 нс 9 час
чтение 1МБ из основной памяти 250 000 нс 9 дней
round trip внутри датацентра 500 000 нс 19 дней
ретрансмит TCP пакета 2 000 000 000 нс 200 лет

Почему RocksDB?
• нужна key-value встроенная БД (store, get, delete)
• попробовали разные варианты:
• MapDB, Tokyo/Kyoto cabinet, leveldb
• «боевые условия»:
• датасет в pagecache
• 80% чтение + 20% запись
• стабильный random read performance при random writes
• HDDs, ~1.5K write IOPs, 6 MB/s
https://goo.gl/dqeBPG

Результаты
• время ответа поискового сервиса:
• время ответа странички поиска:
base: 2086ms
variant 1: 1361ms
кол-во отелей до после
Адриатическое побережье ~30 000 13 сек 30 мс
Рим ~6 000 5 сек 20 мс
София ~300 200 мс 10 мс

Заключение
• скорость – это не только про
конверсию
• посмотрите на
материализацию
• бизнес-процессы могут
облегчить жизнь

Иван Круглов
ivan.kruglov@booking.com
Спасибо!
Ваши вопросы?