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

Тестирование вашей интеграции с ClickHouse

Проверьте свою интеграцию для обоих вариантов развертывания ClickHouse и на наборах данных, которые задействуют систему типов ClickHouse в достаточно реалистичном масштабе, прежде чем отправлять её на рассмотрение. На этой странице определяется, что означает «протестировано» на начальном уровне. Формальная валидация — это отдельный процесс для партнёров, переходящих на более высокие уровни партнёрства.

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

Матрица тестирования​

Охватите оба варианта развертывания. Большинство пользователей работают только с одним из них, и в ряде случаев поведение различается (аутентификация, сеть, доступные возможности).

Проверяйте интеграцию с обоими вариантами и документируйте все пробелы в функциональности на странице интеграции.

Что тестировать​

Функциональная корректность. Проверьте каждый сценарий, который поддерживает ваша интеграция: ингестию, выполнение запросов, определение схемы, обработку ошибок и переподключение. Если ваш продукт показывает SQL конечным пользователям, убедитесь, что запросы, которые генерирует ваш UI, корректно проходят полный цикл.

Покрытие типов данных. ClickHouse поддерживает массивы, кортежи, Map, JSON, Nested, LowCardinality, типы Decimal, варианты Date и DateTime, UUID, IPv4 и IPv6, Enum и типы агрегатных функций. Интеграции часто сталкиваются с проблемами при работе с вложенными массивами, глубоко вложенными кортежами и JSON-столбцами. Ваша клиентская библиотека и UI должны корректно с этим справляться и как минимум выдавать понятную ошибку вместо того, чтобы молча обрезать данные или отображать их некорректно.

Масштаб. Тестируйте на таких размерах результирующих наборов и таком количестве строк, с которыми будут работать ваши пользователи. Для BI-инструментов, ориентированных на конечных пользователей, это часто означает таблицы с сотнями миллионов или миллиардами строк и результирующие наборы от одиночных агрегатов до десятков тысяч строк. Неограниченные чтения (SELECT *) должны предсказуемо завершаться ошибкой или разбиваться на страницы, а не зависать.

Аутентификация. Проверьте как минимум одно TLS-соединение. Если у вас есть настройки аутентификации, протестируйте каждый режим, который вы документируете (имя пользователя и пароль поверх TLS, mTLS, клиентский SSL-сертификат).

Жизненный цикл соединения. Убедитесь, что система корректно ведёт себя при разрыве соединений, перезапуске сервера и медленных запросах. Многие эскалации связаны с обработкой соединений, а не с семантикой запросов.

Полный список доступен в разделе Примеры наборов данных. Следующие четыре набора данных покрывают большинство потребностей при интеграционном тестировании:

  • События GitHub: 3,1 млрд строк с вложенными данными событий. Лучше всего подходит для массивов, Tuple и вложенных типов
  • Данные такси NYC: миллиарды строк с хорошо известной схемой. Подходит для тестирования пропускной способности и чтения
  • Stack Overflow: реляционные данные из нескольких таблиц для BI-сценариев с активным использованием JOIN
  • Hacker News: 28 млн строк, быстро загружается, удобен для быстрых итераций

Для проверки на предельных масштабах используйте WikiStat (~0,5 трлн записей).

Что указать по итогам тестирования​

Когда вы отправляете интеграцию на проверку, укажите:

  • Протестированные версии ClickHouse (Cloud и с открытым исходным кодом)
  • Наборы данных и примерный масштаб (число строк, размер на диске)
  • Типы, которые поддерживает ваша интеграция, и типы, которые она не поддерживает (это станет разделом Known limits в вашей документации)
  • Характеристики производительности, на которые стоит обратить внимание, например пороговые значения размера результирующего набора, при которых поведение меняется

Краткий отчет о тестировании сокращает число итераций при проверке. Достаточно одного абзаца и таблицы.