для упрощения схема такая: (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
Обсуждают сегодня