время, лежали рядом (на диске). Но поиск по ключу был всё равно быстрым? Подход CREATE TABLE t ORDER BY Tuple(key) PARTITION BY timestamp с малой гранулярностью + INSERT INTO t SELECT key, NOW() AS timestamp ведь не будет работать (много партиций будет читаться)?
Строки для одного ключа вставляются довольно локально по времени.
1. а зачем? 2. CH — это колоночная база, тут изначально нельзя сложить строки рядом
1. Чтобы данные на диске локально лежали (есть в вопросе). 2. (Предположительно) можно сложить значения колонок, соответствующих строкам, сходным по какому-то критерию, рядом
1. я это видел, и поэтому и спросил, а зачем это "данные локально на диске лежали" 2. они и лежат по критерию, он называется order by таблицы
1. в запросе идёт выборка данных, которые были созданы примерно в одно и то же время (меньше секторов диска прочитано в случайном порядке — лучше) 2. есть ещё partition by и в условии может быть не префикс order by
1. делайте ключ на основе этого времени или сделайте order by проекцию, получите КОПИЮ изначальных данных, но отсортированных в другом порядке. если набор колонок в проекции "покрывает" запрос, движок из проекции данные прочитает. 2. partition by toDate(ts) order by id, ts -> данные лежат в одной партиции, но благополучно раскиданы по партам этой партиции. меньше секторов прочитано, но данные рядом не лежат
можно ли как-то задать для SummingMergeTree таблицы CREATE TABLE t ( id String, SimpleAggregateFunction(min, DateTime) ) ENGINE = SummingMergeTree PARTITION BY toYYYYMMDD(ts) PRIMARY KEY id ORDER BY id, ts; каким-то образом ограничение на ts для одного id так, чтобы асинхронная группировка не искала id в партициях отстоящих от текущей более, чем на 1? Текущей в том смысле, что я предполагаю, что движок SummingMergeTree ведёт журнал последних вставленных ключей и для них периодически производит аггрегацию. Вставка происходит в последнюю партицию (она обычно — текущая), это так же предположительно запоминается. Понимаю, что слишком много гипотез, но вроде бы они разумные.
если вы знаете что id только в одной партиции, значит добавляйте в where условие по ts. КХ не знает в каких партициях будут лежать данные если вы ему сами не скажете
и что вообще вы подразумеваете под фразой асинзронная группировка? если вы про мерж, то он и так работает только в пределах одной партиции
Одной партиции в смысле partition by?
Это тот механизм, который присущ именно SummingMergeTree
нету такого механизма, все таблицы семейсива *MergeTree работают одинаково. Они склеивают несколько партов в 1 парт большего размера в пределах одной партиции(PARTITION BY) - это называется merge. Никаких других асинхронных групировок нет
прочитайте вот это https://github.com/ClickHouse/ClickHouse/issues/33056 от начала до конца несколько раз и поиграйте с примерами
Обсуждают сегодня