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

Хранилище Citus Columnar разбивает данные на "полосы" (stripes), и каждая полоса разбивается на "куски" (chunks). При выполнении SELECT-запроса, Citus Columnar будет извлекать только те куски, которые содержат необходимые столбцы, и распаковывать их по мере необходимости.

Выбор оптимального размера "полосы" и "куска" зависит от характера ваших запросов и данных. Меньшие "куски" могут улучшить производительность запросов, которые извлекают маленькие объемы данных, но могут привести к более высоким накладным расходам при обработке больших объемов данных. Более крупные "полосы", с другой стороны, могут быть более эффективными при сканировании больших объемов данных.

Кроме того, в Citus Columnar вы можете выбрать алгоритм сжатия, который будет использован для сжатия данных. Выбор алгоритма сжатия может зависеть от типа данных и требований к производительности. Например, алгоритмы с высоким уровнем сжатия могут сэкономить место на диске, но могут потребовать больше процессорного времени при распаковке данных.


Определение оптимального размера "полосы" и блока для columnar-таблиц в Citus зависит от различных факторов, таких как характер данных, шаблоны запросов и характеристики оборудования. Вот несколько рекомендаций:

1. Размер полосы (Stripe Size)(columnar.stripe_row_limit): Оптимальный размер "полосы" может зависеть от типичного размера вашего запроса. Если запросы обычно возвращают большое количество строк, то больший размер "полосы" может быть более эффективным, так как это уменьшит количество операций ввода-вывода. С другой стороны, если запросы часто возвращают небольшое подмножество данных, то меньший размер "полосы" может быть предпочтительнее.

2. Размер блока (Chunk Size)(columnar.chunk_group_row_limit): Это определяет, сколько данных будет сжато за один раз. Меньший размер блока может привести к более высокому коэффициенту сжатия, но может увеличить накладные расходы на сжатие. Больший размер блока может уменьшить накладные расходы, но потенциально снизить коэффициент сжатия.

3. Тестирование и настройка: Важно провести тестирование с реальными данными и запросами, чтобы определить оптимальные параметры для вашей конкретной ситуации. Можно начать с настройки, рекомендованной Citus, а затем поэкспериментировать с различными размерами полос и блоков, чтобы увидеть, как это влияет на производительность запросов и коэффициенты сжатия.

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

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


Выбор алгоритма сжатия для columnar-таблиц в Citus зависит от нескольких факторов, включая характер данных, требования к производительности и характеристики аппаратного обеспечения. Вот некоторые рекомендации, которые могут помочь вам принять решение:

1. none - Этот тип сжатия не применяет никакого сжатия к данным. Он может быть полезен, если ваши данные уже сжаты или если у вас очень высокие требования к производительности и у вас достаточно дискового пространства.

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

3. zstd - Zstandard обеспечивает более высокий коэффициент сжатия по сравнению с LZ4, но при этом требует больше процессорного времени для сжатия и разжатия данных. Этот алгоритм может быть полезен, если у вас ограниченное дисковое пространство, и вы готовы потратить немного больше процессорного времени на сжатие данных.

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


Использование партиций с columnar-таблицами в PostgreSQL и Citus может быть полезным для оптимизации запросов и управления большими наборами данных. Вот несколько шагов, которые можно предпринять для использования партиций с columnar-таблицами:

1. Определите Ключ Партицирования: Выберите столбец, который будет использоваться в качестве ключа партицирования. Часто используемыми ключами партицирования являются временные метки или идентификаторы.

2. Создайте Главную Таблицу: Создайте главную таблицу с определением структуры данных. Укажите, что это будет партиционированная таблица, выбрав тип партицирования (например, RANGE или LIST).  

 CREATE TABLE my_columnar_table (
       column1 datatype,
       column2 datatype,
       ...
   ) PARTITION BY RANGE (column_to_partition_on) ;
SQL

  3. Создайте Партиции: Создайте партиции внутри главной таблицы. Каждая партиция будет иметь определенный диапазон или список значений, который определяется ключом партицирования:

 CREATE TABLE my_columnar_table_part1 PARTITION OF my_columnar_table USING COLUMNAR
   FOR VALUES FROM (value1) TO (value2);
SQL 
 CREATE TABLE my_columnar_table_part2 PARTITION OF my_columnar_table USING COLUMNAR
   FOR VALUES FROM (value3) TO (value4);
SQL

4. Вставка Данных: Вставляйте данные в главную таблицу. PostgreSQL автоматически направит данные в соответствующую партицию на основе ключа партицирования.

5. Оптимизация Запросов: При выполнении запросов, если возможно, используйте условия, которые позволят PostgreSQL выбрать только нужные партиции. Это может значительно улучшить производительность запросов, особенно для больших наборов данных.

6. Управление Партициями: Можно удалять старые партиции или добавлять новые по мере необходимости. Это особенно полезно для управления временными рядами или логами.

7. Индексы: При необходимости можно создать индексы для отдельных партиций.

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


Из дополнительных рекомендаций на данный момент :

SET columnar.enable_custom_scan TO OFF;

SET default_statistics_target = 1000;
SQL