Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,575 views

Published on

Booking.com - популярный сервис по онлайн-бронированию отелей. Поиск отеля, отвечающего заданным характеристикам - это неотъемлемая часть бизнес-модели и основной инструмент для клиента.

При постоянном росте компании вопросу производительности и масштабируемости поиска уделяется много внимания. В результате за время своего существования архитектура поиска претерпела несколько глобальных переделок, начиная от простой базы в MySQL до многокомпонентного распределенного сервиса.

В своей текущей реинкарнации поиск в Booking.com состоит их трех подсистем:
1) сервис auto-complete и устранения неоднозначности (disambiguation) в геопозиции;
2) сервис поиска по отелям и проверки их доступности (availability);
3) система предрасчета цен.

Первые две системы - это высокопроизводительные приложения, написанные на Java. Сервис поиска хранит свои индексы в in-memory хранилище, а данные - во встраиваемой базе данных RocksDB. Логика системы предрасчета цен написана на Perl, а в качестве хранилища используется MySQL.

Приходите на мой доклад, и я расскажу вам, как эволюционировал поиск вместе с ростом компании. Мы подробно рассмотрим текущую архитектуру, и почему мы решили ее сделать именно такой. Ну и, конечно, с какими проблемами нам пришлось бороться и как мы это делали.

Published in: Engineering
  • Be the first to comment

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

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

×