и сответственно результат того что происходит если это делать по всей таблице 🙂

это не учитывая что должны протекать фоновые процессы

и сответственно результат того что происходит если это делать по всей таблице 🙂
можно запрос показать?

именно сам запрос увы нет
долбаное NDA но могу пример накидать

ну, да речь о примере

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

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

SELECT
  field1,
  field2,
  field3,
  sum(p1) as m,
  sum(p2) as m2,
  if(m + m2 > 0, 1, -1) as isVisible
FROM table
group by field1, field2, field3
LIMIT 18000000, 30000

и запросы были бы вида
select key, sum(val) FROM summing GROUP BY key HAVING max(updated_at) > now() - INTERVAL 1 HOUR

Народ, а подскажите кто нибудь

Народ, помогите

у меня кластер с 2 хостами \ репликами
я пытаюсь сделать следующий тестовый сценарий:
- успешно создаю таблицы CREATE TABLE default.test(event_time DateTime, test UInt64) ON CLUSTER "all-replicated" ENGINE MergreTree() ORDER BY tuple() + CREATE TABLE default.test_distr(event_time DateTime, test UInt64) ON CLUSTER "all-replicated" ENGINE Distributed("all-replicated", default, test, test) - четвертый параметр подразумевает, что данные через distributed таблицу должны вставляться поровну в каждый хост кластера

- стопаю сервер на 1м хосте
- успешно вставляю данные  INSERT INTO default.test_distr ...  на втором хосте
- я ожидаю что у меня увеличиться значение  DistributedFilesToInsert в system.metrics на втором хосте
и что default.test MergeTree будет иметь только половину данных, но вместо этого я вижу что в distributed таблице данных столько же сколько в merge tree и никаких ошибок связанных с distributed connection

что я делаю не так?

SELECT
  field1,
  field2,
  field3,
  sum(p1) as m,
  sum(p2) as m2,
  if(m + m2 > 0, 1, -1) as isVisible
FROM table
group by field1, field2, field3
LIMIT 18000000, 30000

30000 в лимите не спроста 🙂

SELECT
  field1,
  field2,
  field3,
  sum(p1) as m,
  sum(p2) as m2,
  if(m + m2 > 0, 1, -1) as isVisible
FROM table
group by field1, field2, field3
LIMIT 18000000, 30000

отдельный AggregatedMergeTree Materialized VIew вам не поможет?

Yuri Alexandrovich, [31.05.20 21:13]
можно ли как-нибудь узнать сколько будут весить данные, которые отдаются КХ по запросу?

те хочешь воcпользоватся  internal_replication='false'?

SELECT
  field1,
  field2,
  field3,
  sum(p1) as m,
  sum(p2) as m2,
  if(m + m2 > 0, 1, -1) as isVisible
FROM table
group by field1, field2, field3
LIMIT 18000000, 30000

LIMIT 18000000, 30000

вот же виновник

он сначала все группирует а потом пропускает 18млн ключей и достает жалкие 30к

LIMIT 18000000, 30000

да весь этот запрос виновник моих бессонных ночей)

В общем, я бы попробовал сделать, как я предложил

замена tmp2 на таблицу c summing agregating движком
но можно и просто ваш запрос чутка улучшить

вы не можете/хотите забирать больше 30к за раз?

не можем

сколько у вас юников?