[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-slowly-changing-dimension::ru":3,"gloss-cluster-slowly-changing-dimension::ru":26,"gloss-next-slowly-changing-dimension::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"slowly-changing-dimension","data-infra","Медленно меняющееся измерение","Медленно меняющееся измерение — описательный атрибут в хранилище, который изменяется изредка и непредсказуемо: тариф клиента, территория менеджера, категория товара, регион аккаунта. Термин обозначает задачу решить, какую историю сохранять. Решение не косметическое. Если перезаписать старое значение, все прошлые факты будут отнесены к текущему состоянию, и прошлогодняя выручка по сегментам будет меняться при каждой переклассификации. Если сохранить, исторические отчёты останутся устойчивыми, но каждый запрос обязан указывать, какая версия ему нужна. Классические ответы принято нумеровать. Тип 1 перезаписывает: просто, без истории, уместно при исправлении настоящих ошибок в данных. Тип 2 при каждом изменении вставляет новую строку измерения с датами действия и признаком актуальности, так что факт соединяется с версией, действовавшей в момент события; это выбор по умолчанию для всего, что попадает в трендовые отчёты, ценой более крупной таблицы и соединений, обязанных учитывать дату действия. Тип 3 хранит колонку с предыдущим значением, и этого хватает, только когда важно одно прошлое состояние. Два практических замечания. Выбор принадлежит бизнес-вопросу, а не моделировщику: кто-то должен заявить, обязаны ли прошлогодние цифры меняться при пересегментации клиента, и ответ разный для разных атрибутов. И измерение типа 2 хорошо ровно настолько, насколько хорош поток изменений за ним: если обновления приходят из источника перезаписью, без захвата изменений, хранилище не восстановит историю, о которой ему не сообщили.","Медленно меняющиеся измерения решают, перезаписать историю или сохранить: сравнение типов 1, 2 и 3 и почему это вопрос бизнеса, а не моделировщика.",null,[11,14,17,20,23],{"slug":12,"name":13},"backfill","Обратное заполнение (Backfill)",{"slug":15,"name":16},"change-data-capture","Захват изменений данных (CDC)",{"slug":18,"name":19},"data-lineage","Происхождение данных (lineage)",{"slug":21,"name":22},"data-warehouse","Хранилище данных (Data Warehouse)",{"slug":24,"name":25},"star-schema","Схема «звезда»",[27,31,34,37,40,44,47,50,51,54,58,61],{"slug":28,"category":5,"name":29,"updated_at":30},"acid","ACID","2026-08-24T02:46:37+00:00",{"slug":32,"category":5,"name":33,"updated_at":30},"ann-search","ANN-поиск (приближённый поиск ближайших соседей)",{"slug":35,"category":5,"name":36,"updated_at":30},"backpressure","Обратное давление (backpressure)",{"slug":38,"category":5,"name":39,"updated_at":30},"batch-processing","Пакетная обработка (Batch Processing)",{"slug":41,"category":5,"name":42,"updated_at":43},"bm25","BM25","2026-08-24T02:46:38+00:00",{"slug":45,"category":5,"name":46,"updated_at":30},"cache","Кэш (Cache)",{"slug":48,"category":5,"name":49,"updated_at":30},"cap-theorem","Теорема CAP (CAP theorem)",{"slug":15,"category":5,"name":16,"updated_at":30},{"slug":52,"category":5,"name":53,"updated_at":30},"chroma","Chroma",{"slug":55,"category":5,"name":56,"updated_at":57},"chunk-overlap","Перекрытие фрагментов","2026-08-24T03:30:02+00:00",{"slug":59,"category":5,"name":60,"updated_at":30},"columnar-storage","Колоночное хранение",{"slug":62,"category":5,"name":63,"updated_at":30},"connection-pooling","Пулинг соединений (Connection Pooling)"]