куда заезжают данные за полгода для аналитической системы в размере ~100 миллиардов строк в основной таблице. Таблица партиционирована по дате ивента и шардирована по индентификатору девайса. Данные относительно равномерно размазаны по нодам кластера. Ребята, подскажите, пожалуйста, из вашего опыта, под такие объемы с какими параметрами кластера вы работали чтобы извлечь максимальный перфоманс запросов? Сколько было нод, их параметры, другие конфигурации? Что можете посоветовать проверить в части настроек? Заранее благодарю за ответы!
Да на вид всё хорошо спроектировано, обычно для очень популярных видов запросов и агрегаций ещё матвью делают, а так выглядит хорошо
Все зависит от сложности запросов и самой форме данных
перфоманс запросов пока не радует. Надо раз в 20 быстрее :)
основной паттерн запроcов имеет следующий вид: сначала из локальных таблиц фильтруются аудитории по своим фильтрам, а затем это все идет в качестве фильтра к распределенной таблице, чтобы данные вычитывались только со своих нод: with tmp_audience_1 as ( select distinct device_id from base_table_local where ... filter for tmp_audience_1 ), tmp_audience_2 as ( select distinct device_id from base_table_local where ... filter for tmp_audience_2 ), ... tmp_audience_n as ( select distinct device_id from base_table_local where ... filter for tmp_audience_n ) select geo_hash_9, sum(cnt) from base_table_distributed where ( device_id in (select device from tmp_audience_1) or device_id in (select device from tmp_audience_2) or ... device_id in (select device from tmp_audience_n) ) group by 1
Это немного не так работает.
base_table_local - действительно одна и та-же или это упрощение для примера?
А зачем тогда 10 дистинктов вместо 1? Так действительно быстрее получается?
это проверю, может есть смысл этого не делать
сколько примерно device_id вылезает из каждого фильтра и суммарно?
в каждом tmp_audience может быть от нескольких тысяч до сотни миллионов уникальных device_id
device_id конечно же ужасный UUID? Или есть шанс переделать на UInt64? Наборы условий фиксированные или полный adhoc?
к сожаленеию, это UUIID и условия фильтрации всегда рандомные
Если тут ничего не менять, то никаких x20 ускорений не получится. Однако: 1. Можно попробовать выключить use_index_for_in_with_subqueries или поднастроить ее новыми сеттингами - https://github.com/ClickHouse/ClickHouse/issues/39865 2. Можно поэкспериментировать с N-Distinct, собрав все условия вместе. И даже совсем отказаться от distinct - IN все равно построит hash таблицу (но см. выше) 3. У вас там получаются point query в основную таблицу, так что еще можно попробовать понизить index_granularity. Так будет меньше читать лишнего с диска, но сожрет больше RAM для PK.
Спасибо за советы!
Обсуждают сегодня