Привет. Выбираю БД под аналитику для IoT-проекта. Сделал proof-of-concept на Кликхаусе,

Question

Привет. Выбираю БД под аналитику для IoT-проекта. Сделал proof-of-concept на Кликхаусе,

всё отлично работает, но есть два вопроса:

1. Как правильнее хранить разнородные данные, учитывая что у разных устройств могут быть разные наборы метрик, при чём в любое время этот набор может быть изменён пользователем?
Один вариант - использовать широкую таблицу по столбцу на каждую метрику и при пользовательских изменениях набора метрик автоматически выполнять ALTER TABLE. Согласно документации операции ADD\DROP COLUMN достаточно дешёвые, пользовательские изменения ожидаются достаточно редко. Правильно ли я понимаю, что в этом варианте основная проблема в максимальном количестве метрик (столбцов)? Или делать туда-сюда ALTER TABLE - не лучшая идея?
Другой вариант - использовать длинную таблицу со столбцами (timestamp, device_id, metric_id, value). Точнее даже две таблицы - для числовых и строковых значений, или два столбца int_value\string_value. Вопрос в том, будут ли при этом оптимально работать аналитические запросы, 90% которых заключается в расчёте продолжительности интервалов времени по каждому станку, когда Метрика1 = Значение1, Метрика2 > Значение2, и т.п? Количество разных метрик в условиях запроса может доходить до 10.

2. Подходит ли кликхаус для данных, которые представляют собой не мгновенные события, а продолжительные по времени значения? Например, устройство сообщает изменение состояния только в момент изменения. При этом всё остальное время оно находится в новом состоянии, которое должно учитываться в запросах по интервалам после времени изменения. В TimescaleDB для таких значений есть функция locf: https://docs.timescale.com/v1.3/using-timescaledb/reading-data#locf
Думал написать подобный запрос на Кликхаусе, но не могу придумать, как сделать без джойнов и всяких order by timestamp desc limit 1, что выглядит нездорово.
Сейчас решил этот вопрос так: устройства отправляют данные в Кафку, самописный консьюмер читает оттуда данные и пишет в кликхаус ежесекундно. Это позволяет считать продолжительность интервалов простым count'ом. Хотелось бы упростить эту логику, и по возможности избавиться от консьюмера.

#backend #clickhouse #database #devops #programming #russian

0

13.05.2019

2 ответов

14 просмотров

Denny [Altinity]

1 >Метрика1 = Значение1, Метрика2 > Значение2 для таких запросов лучше много столбцов (каждая метрика = колонка), возможно я бы для каждого типа девайса сделал свою таблицу, со своим набором столбцов 2 collapsing / aggregating

0

13.05.2019

LeiDruid · Accepted Answer

LeiDruid

Так может вам и использовать какую-нибудь ts db?

0

13.05.2019

184 похожих чатов

Привет. Выбираю БД под аналитику для IoT-проекта. Сделал proof-of-concept на Кликхаусе,

2 ответов

Похожие вопросы