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

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

Амстердам

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

We must deliver the best experience, as frictionless as possible, and grow and adapt fast to the customer’s needby 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

2002 2004 2006 2008 2010 2012 2014 20160

200,000

400,000

600,000

800,000

1,000,000

1,200,000

объектовразмещения

ежедневно забронированных

ночей

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/HhquKLhttps://goo.gl/w1RIhHhttps://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

с звтрк, беспл. отмена

без звтрк, беспл. отмена

с звтрк, плати вперед

без звтрк, плати вперед

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

GFEDCBA

< 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 = минуты

invAV

…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

AVAVAV

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-out4. состав «команды»

Почему встроенная БД?

Почему именно 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/2841832http://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

Спасибо!

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