Comments 22
Интерфейс чем-то похож на aviasales. А заявленные фичи, включая точный выбор дат и сложные маршруты — на kiwi (у них только понятия визы нет, но зато можно направления целыми странами и даже регионами добавлять).
По поводу сложных маршрутов — здесь немного другое. Вернусь к этому комментарию с различием после того, как починю эту фичу.
По поводу целых направлений — здесь делаю «теги», например, Шенген. Далее будут теги вида Пляжи, Ночная жизнь, Прогулки по городу и т.п.
К тому же, хочется задать и Вам вопрос:
Какой фичи не хватает на kiwi?
У kiwi не хватает выделения регионов на карте (есть кружок, который можно таскать и изменять размер, но это не совсем то), и построения сложных запросов по направлениям с использованием тех же регионов/стран и тегов. Например, что-то вроде ("достопримечательности" or "пляжный отдых") and "южная Испания". Плюс все эти агрегаторы пытаются еще и на букинг перенаправить по выбранному направлению, но выбор и планирование гостиниц все равно приходится делать отдельно. В связи с этим вопрос — можно ли создать планировщик, который ищет и перелет, и проживание в пределах наперед заданной суммы денег? Если туда еще и маршруты/расписания/цены с rome2rio (или google maps) пристегнуть для локальных переездов, то получится полный план поездки.
Т.е., того, что у вас реализовано, как я понимаю, в виде гражданство+«Без визы»
Оно умеет работать с обеими интерфейсами. В идеале, хотелось бы получать все (оба), но с этим пока сложности.
upd: habr.com/ru/post/116821
Или Вы будете «парсить» сайты авиакомпаний? У многих есть защита на кол-во запросов от одного и того же IP-адреса.
Конечно, неизвестно является ли цена актуальной или нет (иногда актуальна, иногда нет — как повезет), с этой проблемой приходится мириться.
Стиль Букинга с перегрузкой информации (или дизайна) лучше не копировать.
В Поиске «везде» слишком рябит в глазах.
Видно, что делал программист для программиста )) Хотя, может это и будет для кого-то плюсом.
А так впечатлен, замах хороший ))
Всегда хотелось посмотреть, куда можно вылететь из определенного аэропорта, не бегая по порталам. Спасибо за эту возможность )
Под всем имею в виду:
— логи приложения
— логи фоновых демонов
— логи задач из airflow (частично)
— история запросов к агрегаторам
— история цен для направления (данные для новой фичи История цен)
— остальное :)
Вышеперечисленное хранится всего в двух таблицах:
— первая с движком MergeTree — логи, история и т.п.
— вторая с движком ReplacingMergeTree — для данных, которые нужно записывать поверх предыдущих, чтобы не связываться с update и delete. Делаю только insert (через Buffer-таблицы).
В постгре хранятся справочники:
— аэропорты, страны, информация о необходимости визы и т.д и т.п.
— информация о гео (PostGIS)
— также используется как бд для Apache Airflow
Таблицы постгри используются как справочники в КХ, odbc и другие варианты взаимодействия здесь не используются. Таким образом, обращение к данным постгри происходит с помощью специальных функций dictGet* — это очень удобно:
— не нужно делать джойны!
— sql получается более читаемым и компактным
select origin,
dictGetString(
'airports', -- имя словаря
'airport_name', -- имя поля из словаря
tuple(origin, 'ru')) -- ключ доступа к словарю
from fc.flights
limit 10
Почему
не postgresql:
— уже набралось 0,5 млрд строк Х ~100 колонок, с учетом того, что трафика почти нет. Будет много пользователей — будет больше логов.
— КХ хорошо сжимает данные (много LowCardinality колонок). В постгре такая же таблица будет занимать на диске в ~10 раз больше места. А с учетом того, что используется машинка за 20$ (было за 5$) — это имеет финансовое значение.
— данные часто читаются и часто вставляются. Как либо агрегировать данные не хочу — всех сценариев использования (всех вариантов агрегации) я не смогу предусмотреть
— …
— Выбор для меня очевиден
Попытка решить проблему выбора авиабилетов перед отпуском