Эффективность хранения данных временных рядов

После изучения того, как запрашивать наш датасет статистики Википедии, давайте сосредоточимся на оптимизации его эффективности хранения в ClickHouse. Этот раздел демонстрирует практические методы сокращения требований к объему хранения при сохранении производительности запросов.

Оптимизация типов

Общий подход к оптимизации эффективности хранения заключается в использовании оптимальных типов данных. Рассмотрим колонки project и subproject. Эти колонки имеют тип String, но содержат относительно небольшое количество уникальных значений:

Это означает, что мы можем использовать тип данных LowCardinality(), который использует кодирование на основе словарей. Это приводит к тому, что ClickHouse хранит внутренний ID значения вместо оригинального строкового значения, что, в свою очередь, экономит много места:

Мы также использовали тип UInt64 для колонки hits, который занимает 8 байт, но имеет относительно небольшое максимальное значение:

Учитывая это значение, мы можем вместо этого использовать UInt32, который занимает только 4 байта и позволяет нам хранить до ~4b в качестве максимального значения:

Это уменьшит размер этой колонки в памяти как минимум в 2 раза. Обратите внимание, что размер на диске останется неизменным из-за сжатия. Но будьте осторожны, выбирайте типы данных, которые не слишком малы!

Специальные кодеки

Когда мы имеем дело с последовательными данными, такими как данные временных рядов, мы можем дополнительно улучшить эффективность хранения, используя специальные кодеки. Общая идея заключается в том, чтобы хранить изменения между значениями, а не сами абсолютные значения, что приводит к необходимости в гораздо меньшем объеме пространства при работе с медленно изменяющимися данными:

Мы использовали кодек Delta для колонки time, который хорошо подходит для данных временных рядов.

Правильный ключ сортировки также может сэкономить место на диске. Поскольку мы обычно хотим фильтровать по пути, мы добавим path в ключ сортировки. Это требует воссоздания таблицы.

Ниже мы видим команду CREATE для нашей первоначальной таблицы и оптимизированной таблицы:

И давайте посмотрим на объем занимаемого данным пространством в каждой таблице:

Оптимизированная таблица занимает всего более 4 раз меньше места в сжатом виде.