Перейти к основному содержимому
Перейти к основному содержимому

Соберите ClickHouse с помощью DEFLATE_QPL

  • Убедитесь, что ваша хост-машина соответствует требованиям предварительным условиям QPL.

  • deflate_qpl включен по умолчанию во время сборки cmake. В случае, если вы случайно измените это, пожалуйста, дважды проверьте флаг сборки: ENABLE_QPL=1.

  • Для общих требований, пожалуйста, обратитесь к общим инструкциям по сборке ClickHouse.

Запустите тестирование с DEFLATE_QPL

Список файлов

Папки benchmark_sample в qpl-cmake предоставляют пример запуска тестирования с помощью python-скриптов:

client_scripts содержит python-скрипты для выполнения типичного тестирования, например:

  • client_stressing_test.py: скрипт на python для стресстестирования запросов с [1~4] серверами.
  • queries_ssb.sql: файл со списком всех запросов для Star Schema Benchmark.
  • allin1_ssb.sh: Этот shell-скрипт автоматически выполняет весь процесс тестирования в одном.

database_files означает, что он будет хранить файлы базы данных в соответствии с кодеками lz4/deflate/zstd.

Автоматический запуск тестирования для Star Schema:

После завершения проверьте все результаты в этой папке: ./output/.

Если вы столкнулись с неудачей, пожалуйста, выполните тестирование вручную, как указано в следующих разделах.

Определение

[CLICKHOUSE_EXE] означает путь к исполняемой программе clickhouse.

Окружение

[Самопроверка для IAA]

Ожидаемый вывод будет таким:

Если вы ничего не видите в выводе, это означает, что IAA не готов к работе. Пожалуйста, проверьте настройку IAA еще раз.

Генерация сырых данных

Используйте dbgen, чтобы сгенерировать 100 миллионов строк данных с параметрами: -s 20

Ожидается, что файлы типа *.tbl будут выводиться в ./benchmark_sample/rawdata_dir/ssb-dbgen:

Настройка базы данных

Настройте базу данных с кодеком LZ4

Здесь вы должны увидеть сообщение Connected to ClickHouse server в консоли, что означает, что клиент успешно установил соединение с сервером.

Завершите три шага, упомянутые в Star Schema Benchmark:

  • Создание таблиц в ClickHouse
  • Вставка данных. Здесь следует использовать ./benchmark_sample/rawdata_dir/ssb-dbgen/*.tbl в качестве входных данных.
  • Преобразование "звездной схемы" в денормализованную "плоскую схему".

Настройте базу данных с кодеком IAA Deflate

Завершите три шага так же, как и с lz4 выше.

Настройте базу данных с кодеком ZSTD

Завершите три шага так же, как и с lz4 выше.

[Самопроверка] Для каждого кодека (lz4/zstd/deflate) выполните следующий запрос, чтобы убедиться, что базы данных созданы успешно:

Ожидается следующий вывод:

[Самопроверка для кодека IAA Deflate]

Первый раз, когда вы выполняете вставку или запрос от клиента, консоль сервера clickhouse ожидаемо выпустит этот лог:

Если вы этого никогда не находили, но видите другой лог ниже:

Это означает, что устройства IAA не готовы, вам нужно снова проверить настройку IAA.

Тестирование с одним экземпляром

  • Перед началом тестирования отключите C6 и установите частотный губернатор CPU на performance.
  • Чтобы устранить влияние памяти на перекрестные сокеты, мы используем numactl, чтобы связать сервер с одним сокетом и клиента с другим сокетом.
  • Один экземпляр означает один сервер, подключенный к одному клиенту.

Теперь запустите тестирование для LZ4/Deflate/ZSTD соответственно:

LZ4:

IAA deflate:

ZSTD:

Теперь три лога должны быть выданы, как ожидалось:

Как проверить метрики производительности:

Мы фокусируемся на QPS, пожалуйста, ищите ключевое слово: QPS_Final и собирайте статистику.

Тестирование с несколькими экземплярами

  • Чтобы уменьшить влияние памяти на слишком много потоков, мы рекомендуем запускать тестирование с несколькими экземплярами.
  • Мульти-инстанс означает несколько (2 или 4) серверов, подключенных к соответствующему клиенту.
  • Ядра одного сокета нужно делить поровну и назначать серверам соответственно.
  • Для многопоточности необходимо создать новую папку для каждого кодека и вставить набор данных, следуя аналогичным шагам, как и для одного экземпляра.

Есть 2 отличия:

  • Со стороны клиента необходимо запустить clickhouse с назначенным портом во время создания таблицы и вставки данных.
  • Со стороны сервера необходимо запустить clickhouse с конкретным файлом конфигурации xml, в котором был назначен порт. Все пользовательские файлы xml для множественных инстансов предоставлены в ./server_config.

Предположим, что на каждом сокете 60 ядер и возьмем 2 экземпляра в качестве примера. Запустите сервер для первого экземпляра LZ4:

ZSTD:

IAA Deflate:

[Запускаем сервер для второго экземпляра]

LZ4:

ZSTD:

IAA Deflate:

Создание таблиц и вставка данных для второго экземпляра

Создание таблиц:

Вставка данных:

  • [TBL_FILE_NAME] представляет имя файла, названного по регулярному выражению: *. tbl в ./benchmark_sample/rawdata_dir/ssb-dbgen.
  • --port=9001 обозначает назначенный порт для экземпляра сервера, который также определяется в config_lz4_s2.xml/config_zstd_s2.xml/config_deflate_s2.xml. Для еще большего количества экземпляров вам нужно заменить его значением: 9002/9003, которые обозначают s3/s4 экземпляр соответственно. Если вы не назначите его, порт по умолчанию будет 9000, который уже используется первым экземпляром.

Тестирование с 2 экземплярами

LZ4:

ZSTD:

IAA deflate

Последний аргумент: 2 в client_stressing_test.py обозначает количество экземпляров. Для большего количества экземпляров вам нужно заменить его значением: 3 или 4. Этот скрипт поддерживает до 4 экземпляров.

Теперь три лога должны быть выданы, как ожидалось:

Как проверить метрики производительности:

Мы фокусируемся на QPS, пожалуйста, ищите ключевое слово: QPS_Final и собирайте статистику.

Настройка тестирования для 4 экземпляров аналогична 2 экземплярам выше. Мы рекомендуем использовать данные тестирования для 2 экземпляров в качестве окончательного отчета для обзора.

Советы

Каждый раз перед запуском нового сервера clickhouse убедитесь, что не работает фоновой процесс clickhouse, проверьте и убейте старый:

Сравнив список запросов в ./client_scripts/queries_ssb.sql с официальным Star Schema Benchmark, вы найдете, что 3 запроса не включены: Q1.2/Q1.3/Q3.4. Это связано с тем, что использование CPU% для этих запросов очень низкое < 10%, что означает, что они не могут продемонстрировать различия в производительности.