Comments 22
Шикарная идея! Давно искал подобный сервис.
Интерфейс чем-то похож на aviasales. А заявленные фичи, включая точный выбор дат и сложные маршруты — на kiwi (у них только понятия визы нет, но зато можно направления целыми странами и даже регионами добавлять).
Действительно, там есть часть этих фичей. К сожалению, о них я не знал.
По поводу сложных маршрутов — здесь немного другое. Вернусь к этому комментарию с различием после того, как починю эту фичу.
По поводу целых направлений — здесь делаю «теги», например, Шенген. Далее будут теги вида Пляжи, Ночная жизнь, Прогулки по городу и т.п.
К тому же, хочется задать и Вам вопрос:
Какой фичи не хватает на kiwi?
По поводу сложных маршрутов — здесь немного другое. Вернусь к этому комментарию с различием после того, как починю эту фичу.
По поводу целых направлений — здесь делаю «теги», например, Шенген. Далее будут теги вида Пляжи, Ночная жизнь, Прогулки по городу и т.п.
К тому же, хочется задать и Вам вопрос:
Какой фичи не хватает на kiwi?
У kiwi не хватает выделения регионов на карте (есть кружок, который можно таскать и изменять размер, но это не совсем то), и построения сложных запросов по направлениям с использованием тех же регионов/стран и тегов. Например, что-то вроде ("достопримечательности" or "пляжный отдых") and "южная Испания". Плюс все эти агрегаторы пытаются еще и на букинг перенаправить по выбранному направлению, но выбор и планирование гостиниц все равно приходится делать отдельно. В связи с этим вопрос — можно ли создать планировщик, который ищет и перелет, и проживание в пределах наперед заданной суммы денег? Если туда еще и маршруты/расписания/цены с rome2rio (или google maps) пристегнуть для локальных переездов, то получится полный план поездки.
Мне лично не хватает возможности убрать из поиска Великобританию как пункт пересадки.
Т.е., того, что у вас реализовано, как я понимаю, в виде гражданство+«Без визы»
Т.е., того, что у вас реализовано, как я понимаю, в виде гражданство+«Без визы»
Hashbash А какое именно API использовалось для поиска билетов? Что-то не нашел в статье
Изначально на API aviasales, но прямо сейчас на skyscanner skyscanner.github.io/slate
Оно умеет работать с обеими интерфейсами. В идеале, хотелось бы получать все (оба), но с этим пока сложности.
Оно умеет работать с обеими интерфейсами. В идеале, хотелось бы получать все (оба), но с этим пока сложности.
Был одно время очень удобный для меня сайт eviterra или как-то так. Там можно было прям на карте регионы выделать и любые диапозоны дат, как на циане при поиске квартир.
upd: habr.com/ru/post/116821
upd: habr.com/ru/post/116821
с картой интересно получилось
Вам нужны достаточно большие массивы актуальных данных, которые известны только GDS системам, у которых авиакомпании заводят свои тарифы. Разные авиакомпании работают с разными GDS, кто-то с российской, кто-то с зарубежными, их несколько. Чтобы иметь «все», получается, надо «ходить» по API ко всем. Это ж сколько Вы будете им платить за такое кол-во запросов к ним…
Или Вы будете «парсить» сайты авиакомпаний? У многих есть защита на кол-во запросов от одного и того же IP-адреса.
Или Вы будете «парсить» сайты авиакомпаний? У многих есть защита на кол-во запросов от одного и того же IP-адреса.
Нет, парсить сайты в планы не входит. Да, действительно, актуальные цены стоят денег, которых нет :) На сайте представлены только цены из кэша, которые доступны бесплатно: 1 и 2
Конечно, неизвестно является ли цена актуальной или нет (иногда актуальна, иногда нет — как повезет), с этой проблемой приходится мириться.
Конечно, неизвестно является ли цена актуальной или нет (иногда актуальна, иногда нет — как повезет), с этой проблемой приходится мириться.
Было бы очень полезно, но почему-то у меня везде пусто…
Видно, что dark-тема — для души, но недарковую тоже следовало бы улучшить.
Стиль Букинга с перегрузкой информации (или дизайна) лучше не копировать.
В Поиске «везде» слишком рябит в глазах.
Видно, что делал программист для программиста )) Хотя, может это и будет для кого-то плюсом.
А так впечатлен, замах хороший ))
Стиль Букинга с перегрузкой информации (или дизайна) лучше не копировать.
В Поиске «везде» слишком рябит в глазах.
Видно, что делал программист для программиста )) Хотя, может это и будет для кого-то плюсом.
А так впечатлен, замах хороший ))
Спасибо за отзыв! Светлую тему буду улучшать.
Все совпадения с букингом случайны, почти весь UI взят из vuetify.
Все совпадения с букингом случайны, почти весь UI взят из vuetify.
Всегда хотелось посмотреть, куда можно вылететь из определенного аэропорта, не бегая по порталам. Спасибо за эту возможность )
А можете привести пример, какие промежуточные данные приходится хранить в clickhouse, а главное, почему эти данные пошли в clickhouse, а не в postgresql? Также было бы интересно узнать, как сейчас происходит взаимодействие postgresql -> clickhouse.
В КХ хранится все, кроме справочников.
Под всем имею в виду:
— логи приложения
— логи фоновых демонов
— логи задач из airflow (частично)
— история запросов к агрегаторам
— история цен для направления (данные для новой фичи История цен)
— остальное :)
Вышеперечисленное хранится всего в двух таблицах:
— первая с движком MergeTree — логи, история и т.п.
— вторая с движком ReplacingMergeTree — для данных, которые нужно записывать поверх предыдущих, чтобы не связываться с update и delete. Делаю только insert (через Buffer-таблицы).
В постгре хранятся справочники:
— аэропорты, страны, информация о необходимости визы и т.д и т.п.
— информация о гео (PostGIS)
— также используется как бд для Apache Airflow
Таблицы постгри используются как справочники в КХ, odbc и другие варианты взаимодействия здесь не используются. Таким образом, обращение к данным постгри происходит с помощью специальных функций dictGet* — это очень удобно:
— не нужно делать джойны!
— sql получается более читаемым и компактным
Почему
— уже набралось 0,5 млрд строк Х ~100 колонок, с учетом того, что трафика почти нет. Будет много пользователей — будет больше логов.
— КХ хорошо сжимает данные (много LowCardinality колонок). В постгре такая же таблица будет занимать на диске в ~10 раз больше места. А с учетом того, что используется машинка за 20$ (было за 5$) — это имеет финансовое значение.
— данные часто читаются и часто вставляются. Как либо агрегировать данные не хочу — всех сценариев использования (всех вариантов агрегации) я не смогу предусмотреть
— …
— Выбор для меня очевиден
Под всем имею в виду:
— логи приложения
— логи фоновых демонов
— логи задач из airflow (частично)
— история запросов к агрегаторам
— история цен для направления (данные для новой фичи История цен)
— остальное :)
Вышеперечисленное хранится всего в двух таблицах:
— первая с движком MergeTree — логи, история и т.п.
— вторая с движком ReplacingMergeTree — для данных, которые нужно записывать поверх предыдущих, чтобы не связываться с update и delete. Делаю только insert (через Buffer-таблицы).
В постгре хранятся справочники:
— аэропорты, страны, информация о необходимости визы и т.д и т.п.
— информация о гео (PostGIS)
— также используется как бд для Apache Airflow
Схема
Таблицы постгри используются как справочники в КХ, odbc и другие варианты взаимодействия здесь не используются. Таким образом, обращение к данным постгри происходит с помощью специальных функций dictGet* — это очень удобно:
— не нужно делать джойны!
— sql получается более читаемым и компактным
Пример запроса с dictGet*, без join-а
select origin,
dictGetString(
'airports', -- имя словаря
'airport_name', -- имя поля из словаря
tuple(origin, 'ru')) -- ключ доступа к словарю
from fc.flights
limit 10
Почему
не postgresql:
— уже набралось 0,5 млрд строк Х ~100 колонок, с учетом того, что трафика почти нет. Будет много пользователей — будет больше логов.
— КХ хорошо сжимает данные (много LowCardinality колонок). В постгре такая же таблица будет занимать на диске в ~10 раз больше места. А с учетом того, что используется машинка за 20$ (было за 5$) — это имеет финансовое значение.
— данные часто читаются и часто вставляются. Как либо агрегировать данные не хочу — всех сценариев использования (всех вариантов агрегации) я не смогу предусмотреть
— …
— Выбор для меня очевиден
Картинка мониторинга из Grafana для наглядности объемов данных
Sign up to leave a comment.
Попытка решить проблему выбора авиабилетов перед отпуском