ну если простая не Replicated то .sql (attach ) можно просто положить в /metadata или запускать дочерний процесс (bash) & до старта кх и в нем ждать старта КХ и выполнять скрипт

благодарю!

Datagrip вываливает ошибку: “java.lang.Throwable” и никаких деталей, перебирая части запроса пришел к выводу, что ругается на то, что в группировке используется “WITH TOTALS” версия КХ 20.1.2.4 может есть какой-то баг или специфика?

JDBC вообще не умеет WITH TOTALS, потому что JAVA/JDBC не предусматривает это

используйте group by rollup

@den_crane Помогите, пожалуйста.

Есть таблица

CREATE TABLE data_vault_stage.hubGln (
glnHashKey FixedString(20),
loadDate DateTime,
recordSource String,
glnCode String
) ENGINE = MergeTree() ORDER BY glnHashKey SETTINGS index_granularity = 8192

к ней мат представление

CREATE MATERIALIZED VIEW data_vault_stage.hubGln_mv (
glnHashKey FixedString(20),
lastSeenDate AggregateFunction(max,
DateTime)
) ENGINE = AggregatingMergeTree() ORDER BY glnHashKey SETTINGS index_granularity = 8192
AS
SELECT glnHashKey, maxState(loadDate) AS lastSeenDate FROM data_vault_stage.hubGln GROUP BY glnHashKey

Таблица data_vault_stage.hubGln транкейтится 1 раз в час и в нее вставляются новые данные.

Также есть такая таблица, в которую данные только добавляются через insert-select:

CREATE TABLE data_vault_core.hubGln (
glnHashKey FixedString(20),
loadDate DateTime,
recordSource String,
glnCode String
) ENGINE = MergeTree() ORDER BY glnHashKey SETTINGS index_granularity = 8192

и вот такое представление

CREATE VIEW data_vault_core.hubGln_view (
glnHashKey FixedString(20),
loadDate DateTime,
recordSource String,
lastSeenDate DateTime,
glnCode String) AS SELECT glnHashKey,
loadDate,
recordSource,
lastSeenDate,
glnCode FROM (SELECT glnHashKey,
loadDate,
recordSource,
glnCode FROM data_vault_core.hubGln) ALL LEFT JOIN (SELECT glnHashKey,
maxMerge(lastSeenDate) AS lastSeenDate FROM data_vault_stage.hubGln_mv GROUP BY glnHashKey) USING (glnHashKey)


Есть еще достаточно сложное представление, частью которого является такой подзапрос, а к нему много чего прилоединяется левым соединением:

SELECT glnHashKey,
recordSource,
glnCode FROM data_vault_core.hubGln_view WHERE dateDiff('second',
lastSeenDate,
(SELECT max(lastSeenDate) FROM data_vault_core.hubGln_view)) < (60 * 10)


Собственно, вопрос:
Запрос к сложному представлению исполняется около 10 секунд. В момент исполнения таблица data_vault_stage.hubGln  может быть очищена и в нее могут быть вставлены новые данные (происходит это 1 раз в час). В loadDate всегда вставляется now().
Есть примерно <1% случаев, когда этот запрос может не вернуть данных, полагаю, что это связано с dateDiff, так как не полняется условие в where. Но с другой стороны, при исполнении запроса разве не создается снапшота
всех используемых таблиц на определенный момент времени? Нормально ли для КХ, что он так себя ведет и как можно избежать подобной ситуации?

SELECT glnHashKey,
recordSource,
glnCode FROM data_vault_core.hubGln_view WHERE dateDiff('second',
lastSeenDate,
(SELECT max(lastSeenDate) FROM data_vault_core.hubGln_view)

с т.з. КХ тут два селект и они видят 2 разных таблицы, т.е. SELECT max(lastSeenDate) выполняется над неочищенной таблицей, SELECT glnHashKey над очищенной

Я так и подозревал, а можно ли как-то избежать такой ситуации, помимо смены разницы времени с 10 минут до > 1 часа?

Я так понимаю, если полностью избавиться от представлений в этом запросе, то это тоже не гарантия?

наверное надо создавать hubGln_new, вставлять данные в нее, потом rename table hubGln to hubGln_old, hubGln_new to hubGln; -- одна команда и с точки зрения select она атомарная. drop table hubGln_old

а хотя два селекта опять увидят разное, не знаю, как-то сложнее надо, хранить больше дропать часовые партиции позже

а есть какой-то способ хранить схему таблиц удобным способом?

вряд ли это задача именно под КХ, но я для него пытаюсь сейчас сделать ETL процесс. Пока храню в словаре питоновском просто {table:{field:type,...}}. Видел где-то гугловский protobuf используют

Понял, ок. Спасибо

Добрый вечер.

Вопрос слегка абстрактный:
У меня GROUP BY по 3 полям в 8 таблицах (через merge, в сумме там 1 миллиард записей) выполняется 3 секунды. На что сразу стоит обратить внимание, что можно придумать, чтобы ускорить выборки.

как человек, ещё не очень испорченный кликхаусом, замечу, что с такими вводными 3 секунды - это очень быстро)

но могу дать не менее абстрактный совет как-то готовить данные в отдельные таблички, чтобы селект делал меньше работы

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

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

>GROUP BY по 3 полям
если получается на выходе много строк, то тут ничего удивительного нет.

select number%10003 g, avg(number) from numbers_mt(1000000000) group by g format Null
Elapsed: 0.462 sec

select number%10003 g, number%103 k, avg(number) from numbers_mt(1000000000) group by g, k format Null
Elapsed: 16.653 sec

на выходе 3 значения также