Почему именно из файла надо напрямую?

предполагаю так быстрее? если нужен именно этот файл и все колонки в файле - быстрее наверное прочитать паркет файл из s3 из одного из экзекьюторов, чем прогонять запрос select * from file через query engine?

Не уверен. Возможно первый вариант под собой будет нести не только "прочитать файл", а еще какие-то манипуляции, которые query engine делает за нас.

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

Пишешь в файлы. Берешь это и все https://duckdb.org/ весь твой двх решен

Хм. А аналитики типа в джупитер ноутбуках это будут использовать? А когда не влезет в память?

https://duckdb.org/docs/guides/python/jupyter.html

кликхаус еще для таймсериез хорошо заходит.

я может проглядел, но не понимаю все еще как это поможет если надо будет в память сложить что-то больше, чем память ноутбука

но если требование чтобы лежало в файлах в открытом формате то тут вариантов особо и нет.

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

ага

Очень много всяких контор хранят таймсериес в КХ, просто вертикальные таблицы, работает для всяких сложных запросов лучше чем timeseriesDB

просто в виде sensor_id,timestamp,value?

Атож

метрики всякие удобно еще хранить и потом визуализировать в графане

но у меня не совсем как у метрик вроде паттерн использования