Upload
ontico
View
293
Download
5
Embed Size (px)
Citation preview
Архитектура поиска в 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 мс
Заключение• скорость – это не только про
конверсию• посмотрите на
материализацию• бизнес-процессы могут
облегчить жизнь