Как можно на существующей таблице отключить graphite_rollup? Или переписать секцию graphite_rollup в конфиге таким образом чтоб она ничего не трогала?

Два дня бился с багом из-за которого пропадали метрики (стек bioyino, carbon-clickhouse, clickhouse`), и обнаружил что это КХ усреднял некоторые значения. Таблицы уже задефинированы с `graphite_rollup, и сервер отказывается запускаться когда я убираю эту секцию из конфига...

Всего пара таблиц, определены они вот так им образом:

CREATE TABLE IF NOT EXISTS graphite.data ( 
  Path String,  
  Value Float64,  
  Time UInt32,  
  Date Date,  
  Timestamp UInt32
) ENGINE = GraphiteMergeTree(Date, (Path, Time), 8192, 'graphite_rollup');

Нужно как-то исправить или реинициализовать ENGINE без graphite_rollup.

так пропишите другие правила в graphite_rollup

CREATE TABLE IF NOT EXISTS graphite.data ( 
  Path String,  
  Value Float64,  
  Time UInt32,  
  Date Date,  
  Timestamp UInt32
) ENGINE = GraphiteMergeTree(Date, (Path, Time), 8192, 'graphite_rollup');

можно просто заменить GraphiteMergeTree на MergeTree  

) ENGINE = GraphiteMergeTree(Date, (Path, Time), 8192, 'graphite_rollup');
) ENGINE = MergeTree(Date, (Path, Time), 8192);

в .sql файле

сами парты у всех движков одинаковые, движок влияет на мерж

простите, я тупил. я думал что надо смотреть логи самого хоста, но прилетали они с distributed ( from IP) другого хоста, там всех нашли и удалили. файлы не перезаписываются.

теперь вопрос другого характера.
файлы в distributed накапливаются и он не успевает всем раскидывать.
поддержки в background_distributed_schedule_pool_size только с 20.3

distributed_directory_monitor_batch_inserts=1 уже выставлено.

что ещё можно предпринять безболезненно?

включать синхронный инсерт?
--insert_distributed_sync arg                                    If setting is enabled, insert query into distributed waits until data will be sent to all nodes in cluster.

и инсертить более крупно?

у вас во все ноды инсерт идет? distributed на всех не успевают?

>и инсертить более крупно?
ну, это надо работать =)
>включать синхронный инсерт?
он более efficient? или затормозит апп примерно в похожем порядке?

если разные таблицы в distributed на разных хостах вставлять - поможет? (есть 3-4 крупных). будет у каждой таблицы по потоку?

>>включать синхронный инсерт?
>он более efficient? или затормозит апп примерно в похожем порядке?
вроде выше параллелизм при insert_distributed_sync , я не уверен на 100% , я не пользуюсь вставкой в distributed

>будет у каждой таблицы по потоку?
да

можно вставлять во все хосты во все таблицы и тогда они все будут писать

ок, тогда сначала попробуем в несколько хостов, потом insert distributed sync, спасибо

можно объявить пустые правила:
<graphite_rollup_null incl="rollup_scheme"></graphite_rollup_null>

</yandex>

...
ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/{shard}/graphite_reverse', '{replica}', 'graphite_rollup_null')

Ох благодарю, вроде помогло и запустилось!

Благодарю за ответ! Проблема была в том что просто поменять движ я не смог, и дропать сущестующие таблицы тоже нельзя

Да, мы тоже натыкался на это,  хотя 5тб данных уже несколько раз переписали за 2 года( смена партиционирования и грануляции)

Добрый вечер) Подскажите пожалуйста, возможно ли используя SummingMergeTree со слиянием по дням, обеспечить пользователю выборку записей по диапазону дат с произвольным часовым поясом, либо такой движок здесь не вариант?)

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

ну либо хранить для каждого часового пояса отдельно сумму за день, либо хранить с группировкой до часа (естественно не поможет для таймзон со смещением на 30 минут)

Спасибо) 🙏

Привет!
Допилил чуть PR, чтобы не было конфликтов с текущей веткой master.
Проверил у себя в проекте - работает)
Вообще мы уже довольно давно его используем - основные юзкейсы покрывает: migrate, info, repair, baseline.

Всем привет.
Запускаю CH в докере, ловлю ошибку:
DB::Exception: Memory limit (total) exceeded: would use 1.87 GiB (attempt to allocate chunk of 135793963 bytes), maximum: 1.75 GiB: While executing AggregatingTransform (version 20.6.3.28 (official build))

Хотя прокидываю кастомный конфиг (и вижу что изменения применяются в /var/lib/postgresql/data/preprocessed_configs/config.xml ), но почему-то не могу никак сменить это ограничение.
Мой конфиг такой:

<yandex>
    <users>
        <default>
            <max_server_memory_usage>4000000000</max_server_memory_usage>
        </default>
    </users>


    <profiles>
        <default>
            <max_bytes_before_external_group_by>3000000000</max_bytes_before_external_group_by>
            <max_memory_usage>4000000000</max_memory_usage>
        </default>
    </profiles>

</yandex>