вообще по памяти валится. В чем может быть проблема?
Что вы сделали ? Вы сделали MV на таблицу с движком AggregatingMergeTree ? Какой запрос медленно выполняется ? Какие агрегатные функции используете
1 да. MV на таблицу с движком SimpleAggregateFunction 2 медленно выполняются селекты с группировкой типо таких как на скрине 3 в основном max, один раз min, один раз groupUniqArrayArraySimpleState и один раз anyLastSimpleState
Лучше покажите как создана AggregatingMergeTree и запрос текстом целиком. Если в запросе есть uniq то быстро не будет
запрос создания таблицы или запрос создания вью. uniq есть. но он не критичен. щас без него попробую еще
Таблицы, у вас же вью вставляет в AggregatingMergeTree таблицу
CREATE TABLE db_name.table_name ( run_id_u String, run_start_time SimpleAggregateFunction(min, DateTime64(3)), run_last_timestemp SimpleAggregateFunction(max, DateTime64(3)), order_type SimpleAggregateFunction(max, LowCardinality(String)), some_id SimpleAggregateFunction(max, UInt16), data_source SimpleAggregateFunction(max, LowCardinality(String)), report_type SimpleAggregateFunction(max, LowCardinality(String)), account_id SimpleAggregateFunction(max, LowCardinality(String)), table_name SimpleAggregateFunction(max, LowCardinality(String)), date_from SimpleAggregateFunction(max, Date), date_to SimpleAggregateFunction(max, Date), some_column SimpleAggregateFunction(max, LowCardinality(String)), order_id SimpleAggregateFunction(max, UInt32), run_events_count SimpleAggregateFunction(max, UInt16), event_types_array SimpleAggregateFunction(groupUniqArrayArray, Array(String)), has_extract_message SimpleAggregateFunction(max, UInt8), message SimpleAggregateFunction(max, String), exception_text SimpleAggregateFunction(max, String), message_type_with_error SimpleAggregateFunction(anyLast, LowCardinality(String)), error_log_message_id SimpleAggregateFunction(anyLast, String), request_id SimpleAggregateFunction(max, UInt32), _trace_id SimpleAggregateFunction(max, String), job_id SimpleAggregateFunction(max, Nullable(UInt32)), INDEX run_last_timestemp_idx run_last_timestemp TYPE minmax GRANULARITY 5, INDEX job_date_from_idx date_from TYPE minmax GRANULARITY 5, INDEX job_date_to_idx date_to TYPE minmax GRANULARITY 5, INDEX run_id_universal_idx run_id_universal TYPE bloom_filter GRANULARITY 5, INDEX table_name_idx table_name TYPE bloom_filter GRANULARITY 5 ) ENGINE = AggregatingMergeTree PARTITION BY toYYYYMM(run_start_time) ORDER BY (agency_id, data_source, report_type, account_id, order_id, table_name, run_id_u, run_last_timestemp) SETTINGS index_granularity = 8192
А без индексов не пробовали? Сколько строк в партиции? Возможно только медленнее делают запросы. Как выглядит сам селект?
щас сделаем без индексов. но не похоже что это что-то поменяет селект на котором уже падает вот так. даже фильт по дате не спасает
А зачем maxSimpleState в селект, достаточно же просто max?
ну пробовал может как-то повлияет
Так а сколько записей и какой лимит по памяти? Надо было с этого начать наверное)
в исходной таблице 120 млн строк. 24гб. в аггерированной 30 млн
вроде не много, max_bytes_before_external_group_by = ‘12G’ - так же проходит?
чуть чуть бодрее стало, но больше колонок уже падает
Обсуждают сегодня