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

ок, спасибо

ну по разному можно сделать, можно сделать что агрегаты будут задублированы на все ноды (я так делаю).

можно сделать шардинг так что не нужна будет финальная агрегация и т.п.

понятно, в этом направлении я не думал, спасибо

inflate failed: buffer error                                                                         
IN:INSERT INTO gmc_item_distributed ( gmc_id,item_id,country_code,label_code,updated_at,flag ) FORMAT TabSeparated 

ещё добавлю, что строки при этом все попадают в таблицу. кто сталкивался?

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

что в .err логе КХ ?

Можно по хайпить и на optane?

если бы у меня до него был доступ)

ну так попросите посмотреть тех у кого есть доступ.

inflate failed: buffer error                                                                         
IN:INSERT INTO gmc_item_distributed ( gmc_id,item_id,country_code,label_code,updated_at,flag ) FORMAT TabSeparated 

похоже в коде КХ нету такого <inflate failed: buffer error>
это где-то у вас в приложении / api

https://github.com/ClickHouse/ClickHouse/issues/412

но в отличии от этого случая проблема встречается на файлах любого размера.

странно то что возникает она именно при выгрузке в эту таблицу. остальные - норм, и размеры там больше

😬😬😬 таким образом нужно наоборот увеличивать granularity дополнительного индекса , чтобы ускорить поиск ? Как-то в голове не укладывается .

Больная тема 🙄

конечно нет.

вам просто не подходят skip индексы, они не для вашей задачи

У меня была идея сделать каскад репласинг мердж три таблиц с  партиционированием по дню, месяцу и году соответсвенно
. Сворачиваться будет по одним полям , а людям нужно искать по другим 🙄. Они соедены мердж таблицами , пользователь обращается через них. Соответственно проходит день , данные улетают в месяц и та секция дропается и т.д И это принципиально , чтобы в конце - концов при запросе через какой-то веб им пришло минимальное количество строк , причем последних по дате , и не пришлось бы прикручивать дистинкт, груп бай и тд. Если уж и это не подходит , тогда наверно и кликхаус не подходит 😁

товарищи, я пытаюсь воспроизвести бенчмарк вот этого чувака https://tech.marksblogg.com/billion-nyc-taxi-rides-clickhouse-cluster.html . Создаю Distributed таблицу:

CREATE TABLE trips_mergetree_x3
    AS trips_mergetree_third
    ENGINE = Distributed(perftest_3shards,
                         default,
                         trips_mergetree_third,
                         rand());

И заливаю в нее данные:

INSERT INTO trips_mergetree_x3
    SELECT * FROM trips_mergetree;

Дальше у него написано, что кликхаус через некоторое время сам распихает данные по шардам, но у меня все данные остаются на той ноде, на которой я эту таблицу создал. ЧЯДНТ?

при этом, как и в его примере,

SELECT *
FROM system.clusters
WHERE cluster = 'perftest_3shards'
FORMAT Vertical;

возвращает все три сервера