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

Типы данных

Числовые типы

Пользователи, переносящие данные между ClickHouse и Snowflake, сразу заметят, что ClickHouse позволяет точнее задавать числовые типы. Например, в Snowflake для числовых значений используется тип Number. При этом пользователь должен указать precision (общее количество цифр) и scale (количество цифр справа от десятичной точки) вплоть до общего значения 38. Объявления целых чисел эквивалентны Number и лишь задают фиксированные precision и scale, при этом диапазон остается тем же. Такое удобство возможно потому, что изменение precision (для целых чисел scale равен 0) не влияет на размер данных на диске в Snowflake — при записи на уровне микропартиции используются минимально необходимые байты для заданного числового диапазона. Однако scale влияет на объем хранения, и это компенсируется сжатием. Тип Float64 обеспечивает более широкий диапазон значений ценой потери точности. В отличие от этого, ClickHouse предлагает несколько вариантов знаковых и беззнаковых целых типов и типов с плавающей точкой разной точности. Благодаря этому можно явно указать, какая точность требуется для целых чисел, чтобы оптимизировать накладные расходы на хранение и память. Тип Decimal, эквивалентный типу Number в Snowflake, также поддерживает вдвое большую precision и scale — до 76 цифр. Помимо аналогичного типа Float64, ClickHouse также предоставляет Float32 для случаев, когда точность менее критична, а сжатие важнее всего.

Строки

ClickHouse и Snowflake используют разные подходы к хранению строковых данных. VARCHAR в Snowflake хранит символы Unicode в UTF-8 и позволяет пользователю задавать максимальную длину. Эта длина не влияет ни на хранение, ни на производительность: для хранения строки всегда используется минимально необходимое число байтов, а сама длина служит лишь ограничением, полезным для последующих инструментов. Другие типы, такие как Text и NChar, — это просто псевдонимы этого типа. ClickHouse, напротив, хранит все строковые данные как необработанные байты в типе String (указывать длину не требуется), оставляя выбор кодировки на усмотрение пользователя; при этом функции времени выполнения запроса доступны для разных кодировок. О причинах такого подхода см. в статье “Opaque data argument”. Таким образом, по своей реализации String в ClickHouse в большей степени сопоставим с типом Snowflake Binary. И Snowflake, и ClickHouse поддерживают «collation», что позволяет пользователям переопределять правила сортировки и сравнения строк.

Полуструктурированные типы

Snowflake поддерживает типы VARIANT, OBJECT и ARRAY для полуструктурированных данных. ClickHouse предлагает эквивалентные типы Variant, Object (теперь устаревший в пользу нативного типа JSON) и Array. Кроме того, в ClickHouse есть тип JSON, который заменяет устаревший тип Object('json') и отличается особенно высокой производительностью и эффективностью хранения в сравнении с другими нативными JSON-типами. ClickHouse также поддерживает именованные Tuple и массивы Tuple через тип Nested, что позволяет пользователям явно описывать вложенные структуры. Это позволяет применять кодеки и оптимизации типов на всех уровнях иерархии, в отличие от Snowflake, который требует использовать типы OBJECT, VARIANT и ARRAY для внешнего объекта и не позволяет явно задавать внутреннюю типизацию. Такая внутренняя типизация также упрощает запросы к вложенным числовым значениям в ClickHouse, которые не нужно приводить к другому типу и которые можно использовать в определениях индексов. В ClickHouse кодеки и оптимизированные типы также можно применять к вложенным подструктурам. Это дает дополнительное преимущество: сжатие для вложенных структур остается очень эффективным и сопоставимым со сжатием для плоских данных. Напротив, из-за невозможности применять конкретные типы к подструктурам Snowflake рекомендует выравнивать данные для достижения оптимального сжатия. Snowflake также накладывает ограничения на размер для этих типов данных.

Справочник типов

Наконец, ClickHouse предлагает уникальную возможность хранить промежуточное состояние агрегатных функций. Это состояние зависит от реализации, но позволяет сохранять результат агрегации и затем запрашивать его (с помощью соответствующих функций слияния). Обычно эта возможность используется через materialized view и, как показано ниже, позволяет повысить производительность определённых запросов при минимальных затратах на хранение за счёт сохранения инкрементального результата запросов по вставленным данным (подробнее здесь).
Последнее изменение 25 июня 2026 г.