Ключ шардинга по LastLoginDate нестабилен: версии одного UserId могут попасть на разные шарды и не схлопнуться. Для пользовательских метаданных лучше стабильное распределение по UserId.
CREATE TABLE core.localUserMetadata ON CLUSTER cluster_4x2 (
Ключ шардинга по LastLoginDate нестабилен: версии одного UserId могут попасть на разные шарды и не схлопнуться. Для пользовательских метаданных лучше стабильное распределение по UserId.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Условие
CREATE TABLE core.localUserMetadata ON CLUSTER cluster_4x2 ( UserId String, Country String, LastLoginDate DateTime ) ENGINE = ReplicatedReplacingMergeTree() ORDER BY (UserId);
CREATE TABLE core.userMetadata ON CLUSTER cluster_4x2 ( UserId String, Country String, LastLoginDate Datetime ) ENGINE = Distributed('cluster_4x2', 'core', 'localUserMetadata', cityHash64(LastLoginDate));
Ответ
Ключ шардинга по LastLoginDate нестабилен: версии одного UserId могут попасть на разные шарды и не схлопнуться. Для пользовательских метаданных лучше стабильное распределение по UserId.
Локальный ReplicatedReplacingMergeTree хранит версии, а Distributed направляет записи и собирает чтение с шардов. ON CLUSTER распространяет DDL, но не превращает все шарды в единое место дедупликации. Замените шардирующее выражение на cityHash64(UserId).
Добавьте монотонную версию обновления и передайте её ReplacingMergeTree, если нужна именно последняя бизнес-версия. Без версии выбор связан с порядком вставки/слияния, а не гарантированно с последним входом. Слияния фоновые; для корректного чтения применяют FINAL либо явную агрегацию версий. Параметры репликации, Keeper и default replica path/name должны быть настроены в окружении.
Источник: clickhouse.com, clickhouse.com.