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