для упрощения схема такая: (device_id, metric_id, timestamp, value). Иногда от датчиков приходят "коррекции" за определенный период и данные за указанный период нужно перезаписать, т.е. удалить все сущ данные датчика за период и добавить новые:
alter table on cluster delete where device = ? and timestamp between ? and ?
insert into ...
Т.к. механизм мутаций не дает никаких гарантий когда будет мутация выполнена, имеется такая идея - читать не напрямую из распределенной таблицы, а из представления, которое читает из основной таблицы все, кроме того, что должно было бы быть удалено + из доп таблицы с новыми данными. при коррекциях представление пересоздается.
при получении коррекции
1. alter main_table on cluster delete where device = ? and timestamp between ? and ?
1. insert into main_table ... # вставка новых данных в таблицу. судя по документации "Мутации также упорядочены со вставками - гарантируется, что данные, вставленные в таблицу до начала выполнения запроса мутации, будут изменены, а данные, вставленные после окончания запроса мутации, изменены не будут."
insert into temp_table_{device_id} # вставка новых данных во временную таблицу
2. create or replace view on cluster data_view as select * from main_table where not (device = ? and timestamp between ? and ?) union all temp_table_{device_id}
т.е. будет такой динамический view, который отсекает из основной таблицы то, что должно было бы быть удалено + union all на "временные" таблицы.
количество коррекций - несколько в день, т.е. колич временных таблиц ограничено. по мере применения мутации view будет пересоздаваться, какой-то процесс будет это мониторить.
есть ли навскидку проблемы в таком подходе?
>Иногда от датчиков приходят "коррекции" за определенный период и данные за указанный период нужно перезаписать насколько иногда и эти коррекции важны вообще? вообще мутации можно выполнять синхронно alter table on cluster delete where device = ? and timestamp between ? and ? settings mutation_sync=2
Обсуждают сегодня