Время выполнения запросов

[Ivan Usik]

Есть некая проблема.

Стоит CH на VPS (8Gb, 2xCPU)

Начали тормозить запросы к БД. Сейчас у меня одна таблица и примерно 200 млн. записей.

Выполняю следующего рода запроса:

select count(),sum(click_cnt),avg(impression_cnt) from statistic_by_minutes

Ответ: 

1 rows in set. Elapsed: 1.460 sec. Processed 197.96 million rows, 1.58 GB (135.56 million rows/s., 1.08 GB/s.)

Структура таблице:

┌─name───────────┬─type─────┬─default_type─┬─default_expression─────┐

│ event_date     │ Date     │ DEFAULT      │ toDate(event_datetime) │

│ event_datetime │ DateTime │              │                        │

│ campaign_id    │ Int32    │              │                        │

│ creative_id    │ Int32    │              │                        │

│ company_id     │ Int32    │              │                        │

│ zone_id        │ Int32    │              │                        │

│ impression_cnt │ Int32    │              │                        │

│ domain_hash    │ String   │ DEFAULT      │ \'Unknown\'            │

│ device         │ String   │ DEFAULT      │ \'Unknown\'            │

│ os_type        │ String   │ DEFAULT      │ \'Unknown\'            │

│ browser        │ String   │ DEFAULT      │ \'Unknown\'            │

│ lang           │ String   │ DEFAULT      │ \'Unknown\'            │

│ country_code   │ String   │ DEFAULT      │ \'Unknown\'            │

│ click_cnt      │ Int32    │ DEFAULT      │ CAST(0 AS Int32)       │

└────────────────┴──────────┴──────────────┴────────────────────────┘

ENGINE = MergeTree(event_date, (event_datetime, company_id, zone_id, campaign_id, creative_id), 8192)

Подскажите в чем моя ошибка? Как ускорить время выполнения запроса?, хотя бы такого простого который указал в примере.

Кроме этого видно что сильно возрастает CPU CPU utilization

[Dmitry Berezhnov]

Приветствую.
Попробуйте это https://clickhouse.yandex/reference_ru.html#AggregatingMergeTree

[Ivan Usik]

В clickhouse-server.log заметил еще вот такие ошибки:

2017.04.30 20:13:12.550419 [ 1040834 ] <Debug> MemoryTracker: Peak memory usage (for query): 13.11 MiB.

2017.04.30 20:13:12.550513 [ 1040834 ] <Debug> MemoryTracker: Peak memory usage (for user): 13.11 MiB.

2017.04.30 20:13:12.550569 [ 1040834 ] <Debug> MemoryTracker: Peak memory usage (total): 13.11 MiB.

Возможно здесь есть какая-то связь?

On Sunday, April 30, 2017 at 9:54:05 PM UTC+3, Ivan Usik wrote:

[Vitaliy Lyudvichenko]

воскресенье, 30 апреля 2017 г., 23:15:11 UTC+3 пользователь Ivan Usik написал:

В clickhouse-server.log заметил еще вот такие ошибки:

2017.04.30 20:13:12.550419 [ 1040834 ] <Debug> MemoryTracker: Peak memory usage (for query): 13.11 MiB.

2017.04.30 20:13:12.550513 [ 1040834 ] <Debug> MemoryTracker: Peak memory usage (for user): 13.11 MiB.

2017.04.30 20:13:12.550569 [ 1040834 ] <Debug> MemoryTracker: Peak memory usage (total): 13.11 MiB.

Возможно здесь есть какая-то связь?

Это нормальные сообщения, которые всегда (при logger.level <= debug) выводятся по окончанию запроса.

У начианая с какого-то момента времени скорость выполнения запроса начала деградировать? Какие тайминиги были раньше?

Если у вас при отсутствии выполняемых запросов ClickHouse съедат CPU, это говорит от том, что он в фоне оптимизирует MergeTree-хранилища.

По умолчанию на это выделяется до 16 потоков, что может выесть ресурсы, замедляя SELECT'ы.

Т.к. у вас всего 2 ядра, то имеет смысл уменьшить их количество до 1.

Для этого в настройках default-профиля добавьте:

<background_pool_size>1</background_pool_size>

[Ivan Usik]

Когда запросов нет к clickhouse, то CPU не загружен.
Деградация время выполнения запросов произошло когда кол-во элементов в таблице стало больше 100млн., и с увеличением кол-во элементов все становиться хуже и хуже.

[Vitaliy Lyudvichenko]

А насколько снижение производительности является нелинейным относительно кол-ва строк?

Если у вас набор запросов достаточно фиксирован, то вам действительно иммеет смысл обратить внимание на AggregatingMergeTree, а точнее прибегнуть к достаточно распространненой: схеме одна полная MergeTree таблица + несколько MaterializedView на нее с движком AggregatingMergeTree.

Агрегированные статистики из AggregatingMergeTree в этом случае будут считаться практически моментально, но вставка в основную таблицу будет происходить дольше.

среда, 3 мая 2017 г., 10:31:00 UTC+3 пользователь Ivan Usik написал:

[a...@imagespark.ru]

У меня в базе полтора миллиарда строк, нода одна, запросы выполняются достаточно быстро. Попробуйте фильтровать данные изначально с помощью PREWHERE (https://clickhouse.yandex/reference_ru.html#Секция PREWHERE) и поиграться с первичным ключом (вот тут полезная информация имеется https://groups.google.com/forum/#!topic/clickhouse/eUrsP30VtSU)

Никаких таблиц с стейтом агрегации нет. Собираем кучу показателей по этим данным. Для одной ноды в 96 GB Ram и 16 CPU вполне себе удовлетворительный результат )

воскресенье, 30 апреля 2017 г., 21:54:05 UTC+3 пользователь Ivan Usik написал: