Здравствуйте! Понимаем, что цена — один из основных факторов при выборе отеля.
Стоимость размещения устанавливают сами владельцы объектов. На неё влияют сезонность, востребованность и заполняемость конкретного отеля, поэтому цены могут меняться даже в течение дня.
Мы не управляем ценами отелей напрямую, но со своей стороны стараемся помогать пользователям бронировать выгоднее — в том числе за счёт программы лояльности ГУРУ и промокодов.
Добрый день! Колоночные БД хорошо подходят для аналитики, но для продакшен‑нагрузки с частыми добавлениями и обновлениями записей их производительность может быть недостаточной. Этим и обусловлен наш выбор.
В суммарную нагрузку также входят b2b-клиенты, метапоисковики, различные API-интеграции. Эти каналы формируют значительную долю запросов. Поэтому итоговый RPS получается существенно выше «чистого» b2с.
По факту разработка окупилась примерно за месяц за счёт увеличения скорости поиска, улучшения конверсии и роста доли успешных бронирований.
К тому же три года — это не непрерывная full-time разработка. Пилотная версия была сделана довольно быстро, большая часть времени ушла на портирование поисковой логики, интеграции и тестирование под реальной нагрузкой.
Если посмотреть на механику реальных поисков, нагрузка формируется иначе.
Например, условный «серп» по Москве может включать ~10 000 отелей. Одно открытие такой страницы генерирует около 100 поисковых запросов, сгруппированных батчами. Есть и точечные запросы по одному отелю — их много со стороны b2b-клиентов и партнёров. Это даёт тот общий объём.
Во многих сценариях у нас применяются процентные скидки, комиссии, деление и другие вычисления. Поэтому нам важна точность до копеек — это уменьшает накопление погрешностей и снижает риск расхождений при финальном расчёте цены.
Мы используем Aerospike в других задачах внутри Островка. Но под сценарий, описанный в статье, Aerospike оказался не слишком оптимальным по совокупности параметров. SQLite также рассматривали, но организация in-memory-хранилища была не самой сложной частью
Добрый день! Такой сценарий маловероятен. Если отель подтверждает доступность для OTA-канала (включая нас), он обязан отражать изменения в своей системе. Если бронь была продана в обход систем и возникнет конфликт, мы компенсируем клиенту бронь или предлагаем аналог, а дальше вопрос решается уже с отелем.
Поэтому подобная ситуация — скорее исключение, чем типичный кейс.
Не всегда нужно запускать команды периодически. В админке django-chronograph можно указывать любую management-команду и для этого не нужно допиливать код для celery. У меня мало опыта с celery, поделитесь пожалуйста, как бы вы запускали management-команду из админки в фоне?
Мы не любим celery, так исторически сложилась. Если воспринимать celery, как инструмент для фоновых задач, то нам больше нравится rq+redis или beanstalkd.
За последние 5 лет в django-chronograph мы сделали всего два относительно больших изменения в четырех строках: url изменили на re_path и NullBooleanField изменили на BooleanField(null=True). Еще мы раз в год бампаем версию джанги в pyproject.toml. То есть библиотека просто работает и мы не страдаем от поддержки.
А мы не кричим, просто рассказываем) расти обязательно будем, добавлять еще отели, но 45 отелей — уже хорошее начало, люди этой возможностью активно пользуются. И спасибо за удачу)
Толя Шарифулин, автор текста, никогда не работал на Booking, ошибаетесь. Насчет реализации бизнеса — идеи взяты скорее из опыта предыдущих стартапов наших основателей Кирилла и Сержа, это не первый их бизнес и из опыта сервисов бронирований других стран, например Китая, где лидирует локальный игрок.
Здравствуйте! Понимаем, что цена — один из основных факторов при выборе отеля.
Стоимость размещения устанавливают сами владельцы объектов. На неё влияют сезонность, востребованность и заполняемость конкретного отеля, поэтому цены могут меняться даже в течение дня.
Мы не управляем ценами отелей напрямую, но со своей стороны стараемся помогать пользователям бронировать выгоднее — в том числе за счёт программы лояльности ГУРУ и промокодов.
Добрый день! Колоночные БД хорошо подходят для аналитики, но для продакшен‑нагрузки с частыми добавлениями и обновлениями записей их производительность может быть недостаточной. Этим и обусловлен наш выбор.
В суммарную нагрузку также входят b2b-клиенты, метапоисковики, различные API-интеграции. Эти каналы формируют значительную долю запросов. Поэтому итоговый RPS получается существенно выше «чистого» b2с.
По факту разработка окупилась примерно за месяц за счёт увеличения скорости поиска, улучшения конверсии и роста доли успешных бронирований.
К тому же три года — это не непрерывная full-time разработка. Пилотная версия была сделана довольно быстро, большая часть времени ушла на портирование поисковой логики, интеграции и тестирование под реальной нагрузкой.
Если посмотреть на механику реальных поисков, нагрузка формируется иначе.
Например, условный «серп» по Москве может включать ~10 000 отелей. Одно открытие такой страницы генерирует около 100 поисковых запросов, сгруппированных батчами. Есть и точечные запросы по одному отелю — их много со стороны b2b-клиентов и партнёров. Это даёт тот общий объём.
Во многих сценариях у нас применяются процентные скидки, комиссии, деление и другие вычисления. Поэтому нам важна точность до копеек — это уменьшает накопление погрешностей и снижает риск расхождений при финальном расчёте цены.
Мы используем Aerospike в других задачах внутри Островка. Но под сценарий, описанный в статье, Aerospike оказался не слишком оптимальным по совокупности параметров. SQLite также рассматривали, но организация in-memory-хранилища была не самой сложной частью
Добрый день! Такой сценарий маловероятен. Если отель подтверждает доступность для OTA-канала (включая нас), он обязан отражать изменения в своей системе. Если бронь была продана в обход систем и возникнет конфликт, мы компенсируем клиенту бронь или предлагаем аналог, а дальше вопрос решается уже с отелем.
Поэтому подобная ситуация — скорее исключение, чем типичный кейс.
Добрый день. Добавили!
Не всегда нужно запускать команды периодически. В админке django-chronograph можно указывать любую management-команду и для этого не нужно допиливать код для celery. У меня мало опыта с celery, поделитесь пожалуйста, как бы вы запускали management-команду из админки в фоне?
Мы не любим celery, так исторически сложилась. Если воспринимать celery, как инструмент для фоновых задач, то нам больше нравится rq+redis или beanstalkd.
За последние 5 лет в django-chronograph мы сделали всего два относительно больших изменения в четырех строках:
urlизменили наre_pathиNullBooleanFieldизменили наBooleanField(null=True). Еще мы раз в год бампаем версию джанги вpyproject.toml. То есть библиотека просто работает и мы не страдаем от поддержки.Без скобок бывает трудно понять, что вообще происходит. Поэтому специально двоеточия и скобки на вызовах. (Макс)