В КХ хранится все, кроме справочников.
Под всем имею в виду:
— логи приложения
— логи фоновых демонов
— логи задач из 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 для наглядности объемов данных
Нет, парсить сайты в планы не входит. Да, действительно, актуальные цены стоят денег, которых нет :) На сайте представлены только цены из кэша, которые доступны бесплатно: 1 и 2
Конечно, неизвестно является ли цена актуальной или нет (иногда актуальна, иногда нет — как повезет), с этой проблемой приходится мириться.
Изначально на API aviasales, но прямо сейчас на skyscanner skyscanner.github.io/slate
Оно умеет работать с обеими интерфейсами. В идеале, хотелось бы получать все (оба), но с этим пока сложности.
Действительно, там есть часть этих фичей. К сожалению, о них я не знал.
По поводу сложных маршрутов — здесь немного другое. Вернусь к этому комментарию с различием после того, как починю эту фичу.
По поводу целых направлений — здесь делаю «теги», например, Шенген. Далее будут теги вида Пляжи, Ночная жизнь, Прогулки по городу и т.п.
К тому же, хочется задать и Вам вопрос:
Какой фичи не хватает на kiwi?
Под всем имею в виду:
— логи приложения
— логи фоновых демонов
— логи задач из airflow (частично)
— история запросов к агрегаторам
— история цен для направления (данные для новой фичи История цен)
— остальное :)
Вышеперечисленное хранится всего в двух таблицах:
— первая с движком MergeTree — логи, история и т.п.
— вторая с движком ReplacingMergeTree — для данных, которые нужно записывать поверх предыдущих, чтобы не связываться с update и delete. Делаю только insert (через Buffer-таблицы).
В постгре хранятся справочники:
— аэропорты, страны, информация о необходимости визы и т.д и т.п.
— информация о гео (PostGIS)
— также используется как бд для Apache Airflow
Таблицы постгри используются как справочники в КХ, odbc и другие варианты взаимодействия здесь не используются. Таким образом, обращение к данным постгри происходит с помощью специальных функций dictGet* — это очень удобно:
— не нужно делать джойны!
— sql получается более читаемым и компактным
Почему :
— уже набралось 0,5 млрд строк Х ~100 колонок, с учетом того, что трафика почти нет. Будет много пользователей — будет больше логов.
— КХ хорошо сжимает данные (много LowCardinality колонок). В постгре такая же таблица будет занимать на диске в ~10 раз больше места. А с учетом того, что используется машинка за 20$ (было за 5$) — это имеет финансовое значение.
— данные часто читаются и часто вставляются. Как либо агрегировать данные не хочу — всех сценариев использования (всех вариантов агрегации) я не смогу предусмотреть
— …
— Выбор для меня очевиден
Все совпадения с букингом случайны, почти весь UI взят из vuetify.
Конечно, неизвестно является ли цена актуальной или нет (иногда актуальна, иногда нет — как повезет), с этой проблемой приходится мириться.
Оно умеет работать с обеими интерфейсами. В идеале, хотелось бы получать все (оба), но с этим пока сложности.
По поводу сложных маршрутов — здесь немного другое. Вернусь к этому комментарию с различием после того, как починю эту фичу.
По поводу целых направлений — здесь делаю «теги», например, Шенген. Далее будут теги вида Пляжи, Ночная жизнь, Прогулки по городу и т.п.
К тому же, хочется задать и Вам вопрос:
Какой фичи не хватает на kiwi?