Кстати, кто-нибудь знает, как бороться с GROUP BY на больших

Question

Кстати, кто-нибудь знает, как бороться с GROUP BY на больших

пачках?

У нас стоит ReplacingMergeTree, т.е. в базе данных есть дубликаты, которые неизвестно когда мёржатся. Нужно брать самые актуальные значения по полю <time>. Я использую argMax(<field>, time). Но так же нужна группировка по ID'шнику (ведь есть дубликаты). Clickhouse уже при паре миллионов записей начинает задыхаться (потребляет очень много памяти).

К примеру:

В базе данных есть поле, отвечающее за тип события. API позволяет запросить данные, удовлетворяющие условию: все данные, у которых данные события <values> являются последними.

Грубо говоря, есть данные:

message_id | event_type | event_time
-----------|------------|---------------------
000F010D | 15, | 04:16:04.258567879Z
000F010D | 16 | 04:18:31.027178631Z
000F010D | 12 | 04:55:31.027178631 -- последнее событие
FFF11111 | 1, | 05:16:04.258567879Z
FFF11111 | 2 | 05:18:31.027178631Z
FFF11111 | 15 | 05:18:32.027178631Z
FFF11111 | 15 | 05:18:38.027178631Z
FFF11111 | 11 | 05:55:39.027178631 -- последнее событие
AAAAAAAA | 1, | 06:16:04.258567879Z
AAAAAAAA | 11 | 06:55:39.027178631 -- последнее событие

Запрос:

SELECT
...,
argMax(last_event_type, last_event_time) as max_last_event_time
FROM table_1
WHERE (...)
GROUP BY message_id
HAVING max_last_event_time in (12, 11)
LIMIT 0, 10;

Вернет:

message_id | event_type | event_time
-----------|------------|---------------------
000F010D | 12 | 04:55:31.027178631 -- последнее событие
FFF11111 | 11 | 05:55:39.027178631 -- последнее событие
AAAAAAAA | 11 | 06:55:39.027178631 -- последнее событие

Я делаю подзапрос без GROUP BY с ограничением выборки (в 1000), к примеру. И уже её группирую. Получается по факту некорректно, но это пока единственный способ не задохнуться.