Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Архитектура поиска в Booking.com

•Download as PPTX, PDF•
•
I
Ivan Kruglov

Booking.com - популярный сервис по онлайн-бронированию отелей. Поиск отеля, отвечающего заданным характеристикам - это неотъемлемая часть бизнес-модели и основной инструмент для клиента. При постоянном росте компании вопросу производительности и масштабируемости поиска уделяется много внимания. В результате за время своего существования архитектура поиска претерпела несколько глобальных переделок, начиная от простой базы в MySQL до многокомпонентного распределенного сервиса. В своей текущей реинкарнации поиск в Booking.com состоит их трех подсистем: 1) сервис auto-complete и устранения неоднозначности (disambiguation) в геопозиции; 2) сервис поиска по отелям и проверки их доступности (availability); 3) система предрасчета цен. Первые две системы - это высокопроизводительные приложения, написанные на Java. Сервис поиска хранит свои индексы в in-memory хранилище, а данные - во встраиваемой базе данных RocksDB. Логика системы предрасчета цен написана на Perl, а в качестве хранилища используется MySQL. Приходите на мой доклад, и я расскажу вам, как эволюционировал поиск вместе с ростом компании. Мы подробно рассмотрим текущую архитектуру, и почему мы решили ее сделать именно такой. Ну и, конечно, с какими проблемами нам пришлось бороться и как мы это делали.

1 of 49
Архитектура поиска в 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
Архитектура поиска в Booking.com
Архитектура поиска в Booking.com
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%
поиск эволюция поиска текущая архитектура заключение План
ПОИСК
Архитектура поиска в Booking.com
поиск отбор по атрибутам group fit отбор по availability ранжирование autocomplete & disambiguation определение геопозиции
поиск отбор по атрибутам 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 Спасибо! Ваши вопросы?

More Related Content

Архитектура поиска в Booking.com

  • 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
  • 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. низкие цены большой выбор актуальная информация хороший поиск удобно доступно саппорт говорит на моем языке мобильный сайт скорость мобильное приложение сайт на родном языке и др. наилучшее впечатление
  • 23. поиск отбор по атрибутам group fit отбор по availability ранжирование autocomplete & disambiguation определение геопозиции
  • 24. поиск отбор по атрибутам group fit отбор по 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 с звтрк, беспл. отмена без звтрк, беспл. отмена с звтрк, плати вперед без звтрк, плати вперед
  • 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
  • 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
  • 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. Заключение • скорость – это не только про конверсию • посмотрите на материализацию • бизнес-процессы могут облегчить жизнь

Editor's Notes

  1. отсутствие сортировки по цене
  2. разбиваем задачу по Z24 индексу