Download to read offline
![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. состав «команды»](https://image.slidesharecdn.com/booking-161109081143/85/Booking-com-42-320.jpg)
More Related Content
Similar to Архитектура поиска в Booking.com
Архитектура поиска в Booking.com
- 1.
- 2.
- 3. We must deliverthe best experience, as frictionless as possible, and grow and adapt fast to the customer’s need by Eduardo Shiota
- 4. We must deliverthe best experience, as frictionless as possible, and grow and adapt fast to the customer’s need by Eduardo Shiota
- 5. by Eduardo Shiota Wemust deliver the best experience, as frictionless as possible, and grow and adapt fast to the customer’s need
- 6. 0 200,000 400,000 600,000 800,000 1,000,000 1,200,000 2002 2004 20062008 2010 2012 2014 2016 объектов размещения ежедневно забронированных ночей
- 7. by Eduardo Shiota Wemust deliver the best experience, as frictionless as possible, and grow and adapt fast to the customer’s need
- 8.
- 9.
- 10.
- 13.
- 14. by Eduardo Shiota Wemust deliver the best experience, as frictionless as possible, and grow and adapt fast to the customer’s need
- 15. наилучшее впечатление низкие цены большой выбор актуальнаяинформация хороший поиск удобно доступно саппорт говорит на моем языке мобильный сайт скорость мобильное приложение сайт на родном языке и др.
- 16. наилучшее впечатление низкие цены большой выбор актуальнаяинформация хороший поиск удобно доступно саппорт говорит на моем языке мобильный сайт скорость мобильное приложение сайт на родном языке и др.
- 17. низкие цены большой выбор актуальнаяинформация хороший поиск удобно доступно саппорт говорит на моем языке мобильный сайт скорость мобильное приложение сайт на родном языке и др. наилучшее впечатление
- 18.
- 19.
- 20.
- 21.
- 23. поиск отбор по атрибутам groupfit отбор по availability ранжирование autocomplete & disambiguation определение геопозиции
- 24. поиск отбор по атрибутам groupfit отбор по availability ранжирование autocomplete & disambiguation определение геопозиции деревня Париж, Кигинский район, Республика Башкортостан, Россия ?
- 25. inventory гостиница «Домик с трубой» 1янв. 2 янв. 3 янв. 2 000 ₽ 1750 ₽ 4 янв. 5 янв. 1500 ₽ 1250 ₽ availability гостиница «Домик с трубой» стоит 6500 ₽ с 1 янв. по 5 янв.
- 26. 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 с звтрк, беспл. отмена без звтрк, беспл. отмена с звтрк, плати вперед без звтрк, плати вперед
- 27.
- 28. < 100 000(до 2010 г.) • теплый LAMP-овый стек с 2003 г. • монолитная архитектура inv поиск
- 29. ~150 000 (около2010 г.) • тяжелый расчет availability • надо: ~500 отелей в Париже * 3+ типа комнат * 2+ тарифа = 3000+ расчетов • можем: • 1000 расчетов в сек для 1 ночи • 90 расчетов в сек для 30 ночей inv поиск
- 30. Что делать? 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 ₽
- 31. 1 млн. отелей 3+типа комнат 2+ тарифа 1-30 длительностей проживания данные на 1+ год вперед 100 млрд. цен
- 32. • как неиспортить user experience? • как поддерживать консистентность? Схема с материализацией поиск AVinv материализация AVAV
- 33.
- 34. inv AV … global realtime queue global batch queue realtime queue batch queue расчет нового дня AV AV кластерматериализации материализатор материализатор материализатор материализатор очередь уведомлений источник обновления
- 35. 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
- 36. • ускорение в50-100x раз • быстрый холодный старт • время материализации в норме < 1 мин • метрики + алерты • quality check Результаты поиск AVinv материализация AVAV
- 37. 500 000+ (до~2014 г.) • uwsgi + nginx + perl + mysql • рост бизнеса • новые фичи • поиск по странам и регионам • один запрос = один воркер
- 38. 2014 – 2015гг. • Map-Reduce фреймворк • SOA • большие запросы – быстрее • маленькие запросы – медленнее • IPC overheads AVinv материализация AVAV MR веб-сервер MR MR
- 39.
- 40. Надо что-то менять! •что хотелось: • отойти от устаревших подходов • сохранить MR и SOA • быстрый доступ к AV и другим данным • база данных в которую можно быстро писать • дешевый параллелизм • попробовали Tarantool • будем делать: • Perl => Java • multithreading, меньший константный фактор • данные in-memory • MySQL => RocksDB
- 41. координатор координатор веб-сервер координатор 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
- 42. 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. состав «команды»
- 43. Почему встроенная БД? Почемуименно RocksDB? Почему RocksDB? http://rocksdb.org
- 44. Почему встроенная БД? 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
- 45. Почему встроенная БД? 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 лет
- 46. Почему 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
- 47. Результаты • время ответапоискового сервиса: • время ответа странички поиска: base: 2086ms variant 1: 1361ms кол-во отелей до после Адриатическое побережье ~30 000 13 сек 30 мс Рим ~6 000 5 сек 20 мс София ~300 200 мс 10 мс
- 48. Заключение • скорость –это не только про конверсию • посмотрите на материализацию • бизнес-процессы могут облегчить жизнь
- 49.