Habr_Studio Mar 2 2017 at 19:07

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

18 min

51K

High performance*Search engines*

+48

Comments 34

crezd Mar 2 2017 at 20:19

Спасибо, интересное чтиво.

unabl4 Mar 2 2017 at 23:46

Спасибо. Очень интересно. Даже какое-то девавю. Работая в смежной индустрии, я однажды столкнулся с точно такой же проблемой. И при первых же серьёзных затыках в подсчёте и цены и доступности (availability), идея самого решения была очень схожней, но от реализации отказались ввиду тогда казавшейся сложности и отсутствия ресурсов (как технических, так и людских). Видимо зря )

mrobespierre Mar 3 2017 at 02:23

booking мигрирует на java, «российские гиганты» мигрируют на go, Perl окончательно маргинализируется, печально это

amberovsky Mar 3 2017 at 03:21

Возможно, глупый вопрос — а вы elasticsearch рассматривали?

UFO just landed and posted this here

vian Mar 6 2017 at 16:31

Да рассматривали, и была реализация. Тут правда стоит отступить и сказать что всех подробностей я не приведу т.к. занимался не я. Могу сказать, что его пробовали и для автокомплита (о чем я кратко упомянул отвечая на вопрос из зала) и для основного поиска. В основном поиске уперлись в то, что эластик не справлялся с входящим объемом availability апдейтов.

Если интересуют более подробные детали, спрашивайте. Я могу уточнить.

cmdx Mar 3 2017 at 03:21

Жаль в статье не рассказано, что будет после вашего заказа, это же самое интересное!
Вы только что вернулись из отпуска в Казани?
Отлично! Тогда мы через два дня пришлем вам письмо с предложением снова туда съездить.
Не хотите? Только чемоданы распаковали?
Может тогда через четыре дня? Снова нет? Странно… Вам же там понравилось, вы 5 звезд поставили?
Что, у вас следующий отпуск только через полгода?
А, ну ничего страшного, за это время найдем для вас и пришлем вам на почту 91 вариант где его можно провести.
Оставайтесь с нами, ваш Booking.

CAJAX Mar 3 2017 at 12:42

Внизу писем есть ссылка для отписки, а при заказе есть чекбокс «подписаться на спам».
Хотя один косяк я заметил вчера — букинг держит этот чекбокс выбранным даже в Европе, где это запрещено законом.

Al-Vas Mar 3 2017 at 04:53

Было интересно прочитать, НО когда недавно искал отзыва об конкретных отелях во Вьетнаме, то долго плевался от «удобство» поиска. Куча фильтров по которым можно искать, но по названию не получается, либо это так завуалировано, что не попалось на глаза.

Хотелось просто ввести название отеля и получить ссылку на него — не получилось.
А если перейти в рубрику отели, то вообще будет вывален список всего что есть, но уже же без поиска, если там не один десяток вариантов, то поиск нужного доставляет массу удовольствия.

nikitanaz Mar 3 2017 at 16:10

Пока они не перестанут искать UX-дизайнеров, которые должны выдавать качественную вёрстку, этот момент вряд ли станет лучше. Но статья не про юзабилити всё-таки, эти притензии надо другим людям адресовывать -)

Al-Vas Mar 4 2017 at 19:09

Да я им и на сайте писал, может ту заметят, тем более в тему. Хочется чтобы сервис стал еще удобнее, но порой складывается впечатление что многие разработчики сами не пользуются своим продуктом иначе они бы уже давно поправили кучу неудобных моментов.

ElectroGuard Mar 3 2017 at 06:23

Много езжу, постоянно заказываю отели в букинге, являюсь genius путешественником. При всём уважении к огромной проделанной работе, но поиск пока всё еще работает далеко неидеально. Насколько я помню — то нельзя найти отель по названию, и нельзя найти отель поблизости от указанного места (могу ошибаться, так как уже почти год назад последний раз использовал — летом). Опять же — куча пост-спама с предложениями съездить туда же, где я уже был, раздражает.
В любом случае — спасибо за статью, было очень интересно!

UFO just landed and posted this here

alex3535 Mar 3 2017 at 09:53

Для меня единственный ресурс, который постоянно на глазах меняется в лучшую сторону- это букинг. Год назад снес ихнее приложение Пульс как бесполезное, сейчас установил обратно — совершеннно другое дело, то что надо, помогает работать.
То же самое с поиском на сайте. Про то что нет поиска по каким-либо параметрам- надо понимать есть тут коммерческие моменты. В моем частном случае айрбнб за прошлый год сильно просел в бронировании, а букинг занял эти дни и добавил очень серьезно, суточно.ру и остальные вообще погоды пока не строят, к сожалению. Думаю весь секрет как раз в волшебных календарях и availability, который только у букинга в адеквате. Модель букинга по монетизации- стоит на стороне клиента. А, допустим, Суточно.ру — тупиковая модель, по сути сайта с обьявлениями.
Что не нравится — отзывы на букинге сплошь восторженные. Если ехать приходится, я на них вообще не смотрю, только по негативу пытаюсь определиться.

UFO just landed and posted this here

immaculate Mar 3 2017 at 11:31

Спасибо, пользуюсь booking эпизодически, полезное приложение. И статья интересная.

Честно говоря, часто пользуюсь booking, чтобы оценить, где больше всего отелей и какова средняя цена. Потом приезжаю в нужное место, и беру номер уже на месте. Заранее бронирую редко по двум причинам:

когда приезжаю и смотрю на месте, номера могут серьезно отличаться от того, что на картинках. Личное впечатление ничто не заменит
если не забронировал номер заранее, то можно торговаться. В Таиланде один раз удалось так снять комнату в три раза дешевле (!), чем цена на booking

Понимаю, что от таких как я, booking'у один лишь вред. :) Но я все же изредка бронирую заранее… Допустим, кто-то, чьему мнению я доверяю, говорит мне: «Приедешь в такое-то место, там есть замечательный отель YYY». Личному отзыву доверяю больше, чем отзывам в Интернете, потому что когда читаешь отзывы на booking о тех отелях, где бывал, возникает только каша в голове.

Кто-то бывал до этого только в 5* отелях, и если ему не меняют ежедневно 4 полотенца, напишет, что это ужасная грязная клоака. А кто-то совершенно неприятязательный, жил до этого в индийских мотелях для дальнобойщиков за 100 рупий в день, и пишет паршивому отелю отличный отзыв. Короче, в отзывы даже перестал смотреть, так как они не сообщают никакой полезной информации.

Ivan22 Mar 3 2017 at 15:58

ну уж и бесполезные. Есть реально объективные отзывы вида — на заднем дворе свалка и воняет, номера с окнами туда -не брать. или вайфай в 3-м корпусе не ловит совсем, надо идти в лобби, а в 1и 2м корпусах — в любом номере отличных. Ну и т.д.

ElectroGuard Mar 5 2017 at 12:44

Понятно, что отзывы будут субъективными. Но то, что они 'живые' огромный плюс. В реальности из уже, наверно, 30ти забронированных через букинг отелей, мы 'напоролись' только на одно несоотвествие ожидаемому. И то — нужно было внимательнее смотреть на картинки. Это по Европе, как в других частях мира — сложно сказать.

ElectroGuard Mar 5 2017 at 12:51

По поводу торга — так Азия :) там торговаться — милое дело. Реально можно цены в разы скинуть, видимо даже на отели :)

UFO just landed and posted this here

0x0FFF Mar 3 2017 at 14:40

Коллега, есть такое понятие как «tail latency». Нельзя судить о времени отклика нагруженного сервиса только по среднему, зачастую та же 95-я и 99-я перцентили намного важнее.

UFO just landed and posted this here

vian Mar 6 2017 at 16:51

Справедливое замечание. Поясню. Остальные 60% ответа поисковой страницы это обвязка поиска. Те же самые эксперименты, вытягивание инфы по отелям, ревью и т.д. Там много легаси и все на перле. Брались мы за оптимизацию именно поисковой выборки, а не всей странички.

Смысл in-memory в том, что каждая нода обрабатывая запрос много раз ходит в БД за availability. И ходить в память ближе чем ходить по сети.

anathem Mar 3 2017 at 16:42

И снова читаю всю статью и в конце вижу, что можно было посмотреть-послушать %)

uelkfr Mar 3 2017 at 20:38

А почему вы не сделаете такую фичу, чтобы еще больше нивелировать недостаток неконсистентности availability. Фича заключаются в следующем: делаем AJAX Polling/WebSocket канал, создаем специальные кэширующие сервера для обработки последних изменений материализованной очереди availability, и через этот канал с помощь JavaScript динамически меняем состояние кнопки «Забронировать» на «Не доступно».

vian Mar 6 2017 at 16:59

Руки не дошли. Спасибо за идею :-)

vian Mar 6 2017 at 16:56

Здравствуйте. Я редко пишу за хабре по этому представлюсь. Я Ваня. На видео это я вам рассказываю :-). Если есть вопросы по теме я готов ответить.

vian Mar 6 2017 at 17:00

Да, спасибо TM_content за статью :-)

UFO just landed and posted this here

vian Mar 7 2017 at 14:31

нет, но думаю стоит попробовать в следующей итерации

ElectroGuard Jun 16 2017 at 10:58

Вылез еще один минус букинга. Неверно забронировал номер. Получилось, что не на ту дату (бронировал после 24х часов на текущую ночь и ошибся). И всё — единственный вариант — отмена бронирования (с телефона бронировал) — и 45 евриков ушли в отель, причём это в явном виде не указано. Вот такая правда жизни о 'дешевом' букинге. И не знаю даже, есть ли шанс вернуть.

-1

ElectroGuard Jun 17 2017 at 20:00

Второй минус, по той же причине. Невозможность отмены брони. Случайно что-то недосмотрел пользователь сервиса, заказал неподходящий вариант. Считай — попал на деньги. Отменить действие, замечу, связанное с деньгами, не представляется возможным!!! Варианта два: либо едь живи. Либо просто заберут деньги. Это просто какая-то жесть.

-1

Savochkin Jan 24 2022 at 08:55

Очень интересный доклад и полезный. Возникло несколько вопросов:

>> На входе делается первичная фильтрация тех отелей, которые удовлетворяют нашим критериям на основе инвертированных индексов. У нас есть индекс, ключом являются города, value — это все отели этого города. Например, Париж и все отели, которые находятся в Париже. Есть второй список, например, те отели у которых есть паркинг. Далее если мы пересечём эти два списка — операция дёшевая и быстрая, — мы получим те отели которые в Париже и с парковкой.

т.е. у вас должны поддерживаться N инвертированных индексов по одному на каждую "фичу". В вашем примере для Парижа вы найдете 500 идшников отелей, для has_parking вы получите скорее всего под 100 тыс отелей, по другим фичам кажется вы тоже получите очень много вариантов. Звучит так, что пересечение таких списков - это будет сложная операция. Как это реализовано? наверняка там к-н хаки есть?

>> Как мы обновляем данные availability? Каждая нода независимо от кого-либо берёт и читает эту очередь, применяет update к своему локальному состоянию. Мы посчитали данные один раз, что очень дорого, а применяем их много раз. В этой очереди данные хранятся за последние часы. Если нода отстала, она смогла бы догнать.

я так понял, что внутри шарды все ноды независимы. Может ли возникнуть ситуация, когда пользователь сделает сначала запрос и попадет на 1 ноду, получит результат 1, а потом сделает второй запрос и попадет на ноду 2, которая отстает и в результате получит разные результаты? например, пользовтаель может делать просто рефреши и получать разные результаты? есть ли такое? или может это не проблема?

Show the best of all time