Ключи Сортировки
Ключи сортировки (также известные как ключи упорядочивания) определяют, как данные сортируются на диске и индексируются для таблицы в ClickHouse. При репликации из Postgres ClickPipes устанавливает первичный ключ Postgres таблицы в качестве ключа сортировки для соответствующей таблицы в ClickHouse. В большинстве случаев первичный ключ Postgres служит достаточно хорошим ключом сортировки, так как ClickHouse уже оптимизирован для быстрых сканов, и пользовательские ключи сортировки часто не требуются.
Как описано в руководстве по миграции, для более крупных случаев использования вы должны включить дополнительные колонки помимо первичного ключа Postgres в ключ сортировки ClickHouse для оптимизации запросов.
По умолчанию при использовании CDC выбор ключа сортировки, отличного от первичного ключа Postgres, может привести к проблемам с дедупликацией данных в ClickHouse. Это происходит потому, что ключ сортировки в ClickHouse выполняет двойную роль: контролирует индексирование и сортировку данных, действуя как ключ дедупликации. Самый простой способ решить эту проблему - это определить обновляемые материализованные представления.
Использование обновляемых материализованных представлений
Простой способ определить пользовательские ключи сортировки (ORDER BY) - использовать обновляемые материализованные представления (МВ). Эти представления позволяют вам периодически (например, каждые 5 или 10 минут) копировать всю таблицу с желаемым ключом сортировки.
Ниже приведен пример обновляемого МВ с кастомным ORDER BY и необходимой дедупликацией:
Пользовательские ключи сортировки без обновляемых материализованных представлений
Если обновляемые материализованные представления не работают из-за объема данных, вот несколько рекомендаций, которые вы можете использовать для определения пользовательских ключей сортировки на больших таблицах и преодоления проблем, связанных с дедупликацией.
Выберите колонки ключа сортировки, которые не изменяются для данной строки
При включении дополнительных колонок в ключ сортировки для ClickHouse (в дополнение к первичному ключу из Postgres) мы рекомендуем выбирать колонки, которые не изменяются для каждой строки. Это помогает избежать проблем с согласованностью данных и дедупликацией с ReplacingMergeTree.
Например, в многоарендном SaaS-приложении использование (tenant_id, id) в качестве ключа сортировки является хорошим выбором. Эти колонки уникально идентифицируют каждую строку, и tenant_id остается постоянным для id, даже если другие колонки изменяются. Поскольку дедупликация по id совпадает с дедупликацией по (tenant_id, id), это помогает избежать проблем с дедупликацией данных, которые могут возникнуть, если tenant_id изменится.
Установите Replica Identity для таблиц Postgres на пользовательский ключ сортировки
Для корректной работы CDC Postgres важно изменить REPLICA IDENTITY на таблицах, чтобы включить колонки ключа сортировки. Это необходимо для правильной обработки DELETE.
Если REPLICA IDENTITY не включает колонки ключа сортировки, CDC Postgres не захватит значения колонок, отличных от первичного ключа - это ограничение логического декодирования Postgres. Все колонки ключа сортировки, помимо первичного ключа в Postgres, будут содержать null. Это влияет на дедупликацию, что означает, что предыдущая версия строки может не быть дедуплицирована с последней удаленной версией (где _peerdb_is_deleted установлен в 1).
В приведенном выше примере с owneruserid и id, если первичный ключ еще не включает owneruserid, вам нужно создать UNIQUE INDEX на (owneruserid, id) и установить его в качестве REPLICA IDENTITY для таблицы. Это гарантирует, что CDC Postgres захватывает необходимые значения колонок для точной репликации и дедупликации.
Ниже приведен пример, как это сделать на таблице событий. Убедитесь, что вы применили это ко всем таблицам с измененными ключами сортировки.
