Всем привет! Прошу помощи экспертного сообщества! У нас есть большая

Distributed таблица с ивентами - несколько миллиардов записей. В ней есть следующая информация: ts ивента, геохэши, идентификатор пользователя. Partition by event_date, Primary key по event_date, ts и геохэшам. На идентификаторе пользователя (длинная строка) стоит bloom index с гранулярностью 2. Use case у нас такой:
1. Сперва по заданным ts, геохэшам и другим условиям находим ВСЕХ пользователей, удовлетворяющих условиям фильтрации (каждый раз это может быть от нескольких тысяч до миллионов),
2. Затем по найденным пользователям по заданным геохэшам отображаем ВСЕ их ивенты без учета TS
Получается, что подзапрос таблицы самой к себе. С движком Distributed это не работает как надо... Какие есть идеи?

Global in

в этом случае падает по памяти на небольшой выборке (на каждой ноде у нас 64Gb)

Ну так запрос киньте сюда.

WITH pre_select AS ( SELECT user_id FROM db.event AS b WHERE ((ts >= '2023-03-04 08:00:00') AND (ts <= '2023-04-11 08:00:00')) AND ((event_date >= '2023-03-04') AND (event_date <= '2023-04-11')) AND (geo_hash_2 IN ('w0', 'w2', 'w8', 'w3', 'w9')) AND (geo_hash_3 IN ('w0r', 'w0x', 'w0z', 'w22', 'w23', 'w26', 'w27', 'w2k', 'w2m', 'w2q', 'w2r', 'w28', 'w29', 'w2d', 'w2e', 'w2s', 'w2t', 'w2w', 'w2x', 'w2b', 'w2c', 'w2f', 'w2g', 'w2u', 'w2v', 'w2y', 'w2z', 'w82', 'w83', 'w86', 'w87', 'w8k', 'w88', 'w89', 'w8d', 'w8e', 'w8s', 'w8b', 'w8c', 'w8f', 'w8g', 'w8u', 'w1p', 'w30', 'w31', 'w34', 'w35', 'w3h', 'w3j', 'w3n', 'w3p', 'w90', 'w91', 'w94', 'w95', 'w9h')) ) SELECT geo_hash_5, sum(cnt) AS events_count FROM dev_igor.bid WHERE (geo_hash_2 IN ('w0', 'w2', 'w8', 'w3', 'w9')) AND (geo_hash_3 IN ('w0r', 'w0x', 'w0z', 'w22', 'w23', 'w26', 'w27', 'w2k', 'w2m', 'w2q', 'w2r', 'w28', 'w29', 'w2d', 'w2e', 'w2s', 'w2t', 'w2w', 'w2x', 'w2b', 'w2c', 'w2f', 'w2g', 'w2u', 'w2v', 'w2y', 'w2z', 'w82', 'w83', 'w86', 'w87', 'w8k', 'w88', 'w89', 'w8d', 'w8e', 'w8s', 'w8b', 'w8c', 'w8f', 'w8g', 'w8u', 'w1p', 'w30', 'w31', 'w34', 'w35', 'w3h', 'w3j', 'w3n', 'w3p', 'w90', 'w91', 'w94', 'w95', 'w9h')) AND (user_id GLOBAL IN ( SELECT user_id FROM pre_select )) GROUP BY 1 Query id: 8de9c63f-921a-425a-af40-52c98f9d5c5b 0 rows in set. Elapsed: 192.714 sec. Received exception from server (version 23.3.1): Code: 32. DB::Exception: Received from cluster_name.net:9000. DB::Exception: Attempt to read after eof: while receiving packet from cluster_name:9000: While executing Remote: While processing user_id GLOBAL IN (_subquery2). (ATTEMPT_TO_READ_AFTER_EOF)

WITH pre_select AS ( SELECT user_id FROM db.event AS AS b WHERE ((ts >= '2023-03-04 08:00:00') AND (ts <= '2023-04-11 08:00:00')) AND ((event_date >= '2023-03-04') AND (event_date <= '2023-04-11')) AND (geo_hash_2 IN ('w0', 'w2', 'w8', 'w3', 'w9')) AND (geo_hash_3 IN ('w0r', 'w0x', 'w0z', 'w22', 'w23', 'w26', 'w27', 'w2k', 'w2m', 'w2q', 'w2r', 'w28', 'w29', 'w2d', 'w2e', 'w2s', 'w2t', 'w2w', 'w2x', 'w2b', 'w2c', 'w2f', 'w2g', 'w2u', 'w2v', 'w2y', 'w2z', 'w82', 'w83', 'w86', 'w87', 'w8k', 'w88', 'w89', 'w8d', 'w8e', 'w8s', 'w8b', 'w8c', 'w8f', 'w8g', 'w8u', 'w1p', 'w30', 'w31', 'w34', 'w35', 'w3h', 'w3j', 'w3n', 'w3p', 'w90', 'w91', 'w94', 'w95', 'w9h')) LIMIT 1 ) SELECT geo_hash_5, sum(cnt) AS events_count FROM db.event WHERE (geo_hash_2 IN ('w0', 'w2', 'w8', 'w3', 'w9')) AND (geo_hash_3 IN ('w0r', 'w0x', 'w0z', 'w22', 'w23', 'w26', 'w27', 'w2k', 'w2m', 'w2q', 'w2r', 'w28', 'w29', 'w2d', 'w2e', 'w2s', 'w2t', 'w2w', 'w2x', 'w2b', 'w2c', 'w2f', 'w2g', 'w2u', 'w2v', 'w2y', 'w2z', 'w82', 'w83', 'w86', 'w87', 'w8k', 'w88', 'w89', 'w8d', 'w8e', 'w8s', 'w8b', 'w8c', 'w8f', 'w8g', 'w8u', 'w1p', 'w30', 'w31', 'w34', 'w35', 'w3h', 'w3j', 'w3n', 'w3p', 'w90', 'w91', 'w94', 'w95', 'w9h')) AND (user_id GLOBAL IN ( SELECT user_id FROM pre_select )) GROUP BY 1 Query id: e7b2f194-3896-4901-b25d-f849a6ddb882 ┌─geo_hash_5─┬─events_count─┐ │ w281w │ 2 │ │ w0z8k │ 18 │ │ w283f │ 88 │ │ w2833 │ 1 │ │ w2864 │ 71 │ │ w283c │ 174 │ │ w0z87 │ 12 │ │ w2839 │ 1 │ │ w0xxf │ 61 │ │ w281r │ 2 │ │ w0xxg │ 470 │ │ w82n0 │ 28 │ └────────────┴──────────────┘ 12 rows in set. Elapsed: 10.766 sec. Processed 13.20 million rows, 1.10 GB (1.23 million rows/s., 102.54 MB/s.)

bloom index это конечно здорово, но он не всегда работает хорошо. Я бы сделал отдельные индексные таблицы отсортированные по дате и геохешу (для каждого геохеша своя), а основную таблицу отсортировал по user_id. Чуть больше места и кое-какие проблемы с целостностью данных, зато будет быстро, потому как оба поиска будут идти по нормальному PK.

Спасибо за совет! У меня 9 геохешей вот только…

А что такого в 9-ти? Не 90 же. Какая разница - отдельная колонка или таблица? Вы же в запросах отдельно к каждому обращаетесь. Конечно можно их умять и в одну таблицу, но зачем?

но там террабайты данных

и по идее, геохэш 9 всегда включает в себя все предыдущие геохэши