Size: a a a

ClickHouse не тормозит

2021 March 10

K

Konstantin Ilchenko in ClickHouse не тормозит
Подскажите пожалуйста такой вопрос по оптимизации, имеем вот такую таблицу
CREATE TABLE table1
 `app_id` Int64,
 `event_name` LowCardinality(String),
 `event_time` DateTime,
 `attr1` String,
 `attr2` String,
)
 ENGINE = MergeTree()
 PARTITION BY toYYYYMMDD(toDate(event_time))
 ORDER BY (app_id, event_name)
 SETTINGS index_granularity = 8192, enable_mixed_granularity_parts = 1


Запрос 1
SELECT
 app_id,
 attr1,
 anyLast(attr2) AS attr2
FROM
 (
   SELECT app_id, attr1, attr2
   FROM table1
   WHERE (app_id in (1,2,3)) AND (event_name IN ('install', 'event'))
   ORDER BY app_id, event_time
 )
GROUP BY app_id, attr1;


Запрос 2
SELECT
 app_id,
 attr1,
 anyLast(attr2) AS attr2
FROM
 (
   SELECT app_id, attr1, attr2
   FROM table1
   WHERE (app_id in (1,2,3)) AND (event_name IN ('install', 'event'))
   ORDER BY event_time
 )
GROUP BY app_id, attr1;


Разница между запросами только в том, что во втором из ORDER  BY убран app_id

Помогите понять почему Запрос 2 отрабатывает в 2 раза быстрее первого? Я думал что будет наоборот, так как app_id идёт первым в ключе сортировки, то для КХ будет меньше работы при сортировке и последующей группировке.
источник

DC

Denny Crane [not a Y... in ClickHouse не тормозит
Konstantin Ilchenko
Подскажите пожалуйста такой вопрос по оптимизации, имеем вот такую таблицу
CREATE TABLE table1
 `app_id` Int64,
 `event_name` LowCardinality(String),
 `event_time` DateTime,
 `attr1` String,
 `attr2` String,
)
 ENGINE = MergeTree()
 PARTITION BY toYYYYMMDD(toDate(event_time))
 ORDER BY (app_id, event_name)
 SETTINGS index_granularity = 8192, enable_mixed_granularity_parts = 1


Запрос 1
SELECT
 app_id,
 attr1,
 anyLast(attr2) AS attr2
FROM
 (
   SELECT app_id, attr1, attr2
   FROM table1
   WHERE (app_id in (1,2,3)) AND (event_name IN ('install', 'event'))
   ORDER BY app_id, event_time
 )
GROUP BY app_id, attr1;


Запрос 2
SELECT
 app_id,
 attr1,
 anyLast(attr2) AS attr2
FROM
 (
   SELECT app_id, attr1, attr2
   FROM table1
   WHERE (app_id in (1,2,3)) AND (event_name IN ('install', 'event'))
   ORDER BY event_time
 )
GROUP BY app_id, attr1;


Разница между запросами только в том, что во втором из ORDER  BY убран app_id

Помогите понять почему Запрос 2 отрабатывает в 2 раза быстрее первого? Я думал что будет наоборот, так как app_id идёт первым в ключе сортировки, то для КХ будет меньше работы при сортировке и последующей группировке.
>Я думал что будет наоборот, так как app_id идёт первым
иногда эта оптимизация вредит.

Т.е. в olap неиспользование индексов зачастую улучшает перфоманс
источник

K

Konstantin Ilchenko in ClickHouse не тормозит
Denny Crane [not a Yandex bot]
>Я думал что будет наоборот, так как app_id идёт первым
иногда эта оптимизация вредит.

Т.е. в olap неиспользование индексов зачастую улучшает перфоманс
Понял, может быть где-то можно почитать о логике планировщика запросов кроме исходников?
источник

DC

Denny Crane [not a Y... in ClickHouse не тормозит
Konstantin Ilchenko
Понял, может быть где-то можно почитать о логике планировщика запросов кроме исходников?
так а нету планировщика, нечего читать.
если order by таблицы и запроса совпадает в префиксе , то индекс будет использован.
источник

K

Konstantin Ilchenko in ClickHouse не тормозит
Denny Crane [not a Yandex bot]
так а нету планировщика, нечего читать.
если order by таблицы и запроса совпадает в префиксе , то индекс будет использован.
т.е. order by запроса должен полностью совпадать с префиксом и при частичном совпадении по начальным колонкам табличный order by никогда не применится?
источник

DC

Denny Crane [not a Y... in ClickHouse не тормозит
Konstantin Ilchenko
т.е. order by запроса должен полностью совпадать с префиксом и при частичном совпадении по начальным колонкам табличный order by никогда не применится?
если в таблице order by a,b
то в запросе должно быть order by a или order by a,b или order by a, d

вплоть до того что если будет
where a=1 order b -- то индекс не будет использован, надо писать where a=1 order a, b
источник

K

Konstantin Ilchenko in ClickHouse не тормозит
понял, спасибо
источник

A

Andrey in ClickHouse не тормозит
Такой вопрос: у нас тыщ 10 таблиц и 2 реплики, активная запись. Обе реплики при грубом рестарте (используется оператор от altinity) отваливаются по причине незакоммиченных в zk партов у разных таблиц
источник

A

Andrey in ClickHouse не тормозит
Я сейчас прикручиваю graceful termination, потому что оператор в него не умеет
источник

A

Andrey in ClickHouse не тормозит
Но случаи грубого завершения возможны, так что все ещё остаются две c половиной настройки
источник

A

Andrey in ClickHouse не тормозит
Одна про количество подозрительных партов, которых нет в zk, вторая про их процентное соотношение, а третья - булевая переменная, отвечающая за sanity check
источник

A

Andrey in ClickHouse не тормозит
Это то, что я выкопал из исходников
источник

A

Andrey in ClickHouse не тормозит
Вопрос про третий пункт, который хз от чего зависит. Ссылку на код смогу дать чуть позже, если надо
источник

A

Andrey in ClickHouse не тормозит
Цель: минимизировать случаи выставления флага force_restore_data
источник

N

Nikolay in ClickHouse не тормозит
Поделитесь опытом. Использует ли кто то SAN или все на локальных дисках ?
источник

K

KiLEX 萊赫 in ClickHouse не тормозит
Nikolay
Поделитесь опытом. Использует ли кто то SAN или все на локальных дисках ?
Для старых партиций, через iSCSI
источник

N

Nikolay in ClickHouse не тормозит
А на Fibre Chennel может кто то использует для всех данных ?
источник

N

Nikolay in ClickHouse не тормозит
KiLEX 萊赫
Для старых партиций, через iSCSI
Спасибо.А почему iSCSI выбрали ?
источник

K

KiLEX 萊赫 in ClickHouse не тормозит
Nikolay
Спасибо.А почему iSCSI выбрали ?
Приемлимо медленный и отсносительно дешёвый. Ну и позволяет без лишних затрат десятки серверов с разных стоек подцепить к одному СХД
источник

DN

Demetra Nadya in ClickHouse не тормозит
Что выбрать для бекапа и нужна ли репликация? Таблицы merging tree с партициями по месяцам. Размер базы - несколько ГБ.
источник