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

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

9. A/B
тестирование

10. Buy now
Buy now
vs

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. низкие цены
большой выбор
актуальная информация
хороший поиск
удобно
доступно
саппорт говорит на моем языке
мобильный сайт
скорость
мобильное приложение
сайт на родном языке
и др.
наилучшее
впечатление

18. почему важна
скорость?
https://goo.gl/DP593v
https://goo.gl/HhquKL
https://goo.gl/w1RIhH
https://goo.gl/brL9Zx
https://goo.gl/EbXZl1
https://goo.gl/Gcaunb

19. поиск
90%
10%
поиск
50%
50%

20. поиск
эволюция
поиска
текущая архитектура
заключение
План

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

32. поиск
autocomplete
&
disambiguation
t = минуты

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

38. Текущая архитектура

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. Заключение
• скорость – это не только про
конверсию
• посмотрите на
материализацию
• бизнес-процессы могут
облегчить жизнь

48. Иван Круглов
ivan.kruglov@booking.com
Спасибо!
Ваши вопросы?