Забывающие базы данных

Почему знания об устройстве данных устаревают — и что с этим делать

Представьте: вы обучили систему работать с хранилищем данных. Она знает, какие таблицы за что отвечают. Знает, как они связаны. Знает, что запрос «покажи данные по студентам математического факультета» требует соединения трёх конкретных таблиц через конкретные поля.

Проходит два года.

Таблица SIS_DEPARTMENT переименована в ACADEMIC_DEPT. Поле DEPT_CODE теперь называется DEPT_ID и содержит UUID вместо числового кода. Таблица SIS_ENROLLMENT разделена на SIS_ENRL_ACTIVE и SIS_ENRL_HISTORY.

Система по-прежнему уверенно строит запросы. Только теперь они не работают.

Базы данных живут и меняются

Хранилище данных — это не статичный объект. Это живая система, которая отражает изменения в организации, технологиях и понимании данных.

Схемы эволюционируют: таблицы добавляются, переименовываются, разделяются, сливаются, удаляются. Поля меняют типы, названия, смысл. Данные мигрируют из одной структуры в другую. Логика агрегации пересматривается.

В университете — новый модуль для международных студентов, отдельные таблицы для аспирантов. В банке — регуляторные требования меняют структуру хранения финансовых данных. В ритейле — слияние двух компаний объединяет две схемы с частично пересекающимися таблицами.

Каждое из этих изменений делает часть накопленных знаний о схеме устаревшей.

Золотой стандарт, который протухает

В исследованиях систем работы с данными принято создавать «золотые» эталоны: набор вопросов с правильными ответами, по которым оценивают качество системы.

Эти эталоны создаются в конкретный момент времени. Специалисты пишут вопросы, проверяют ответы на живой базе, фиксируют правильные SQL-запросы. Всё верно — на момент создания.

Через два года картина другая. Часть эталонных запросов обращается к таблицам, которые переименованы. Часть использует поля, которых больше нет. Часть даёт правильный с технической точки зрения результат — но неправильный по смыслу, потому что изменилась бизнес-логика.

Это называется протуханием золотого стандарта (gold staleness). Эталон остаётся в базе знаний, но перестаёт соответствовать реальности.

В долгоживущих корпоративных хранилищах доля таких протухших эталонов может достигать 20–30% за два-три года. Это не катастрофа — это норма. Данные меняются быстрее, чем документация за ними успевает.

Почему система продолжает ошибаться уверенно

Самое коварное свойство устаревших знаний — система о них не знает.

Если в системе хранится информация «для вопросов о факультетах нужна таблица SIS_DEPARTMENT», она будет использовать эту таблицу. Уверенно. Каждый раз.

Пока кто-то не заметит, что отчёты пустые. Или пока данные не начнут расходиться с реальностью. Или пока системный администратор не скажет: «SIS_DEPARTMENT удалили полгода назад, теперь это ACADEMIC_DEPT».

В отличие от программного кода, где переименование переменной вызывает ошибку компиляции, в SQL нет механизма, который автоматически предупреждает все системы о смене имени таблицы. Зависимости неявны. Уведомления не отправляются.

Три вида устаревания

Не всё устаревание одинаково.

Структурное устаревание — самое видимое. Таблица переименована, поле удалено, тип изменился. Запросы с устаревшими именами дают ошибку. Это обнаруживается быстро — как только запрос выполняется.

Семантическое устаревание — скрытое. Таблица та же, поле то же — но смысл изменился. Поле STATUS раньше имело значения active и inactive. После миграции значения стали A и I. Технически запрос работает. Фактически фильтр WHERE STATUS = 'active' теперь не возвращает ничего.

Контекстное устаревание — самое сложное. Данные не изменились, но изменилось понимание бизнеса. «Студент первого курса» раньше означало одно, после введения новой классификации программ — другое. Правило, которое раньше давало верный результат, теперь выдаёт данные за прошлые периоды, которые в реальности уже не существуют.

Временной граф как решение

Традиционные базы данных помнят только текущее состояние. Что было вчера — неизвестно. Что изменилось месяц назад — тоже. История есть только там, где её специально ведут.

Исследования в области темпоральных баз данных и временных графов предлагают другой подход: хранить не только текущее состояние схемы, но и всю историю её изменений вместе с метками времени.

Тогда можно спросить: «как выглядела схема на момент создания этого эталонного запроса?» И воспроизвести контекст, в котором запрос был верным.

Это решает проблему ретроспективной оценки: можно честно сравнивать результаты разных систем, созданных в разное время, на одних и тех же данных — не «на текущей схеме», а «на схеме того периода».

Метрика: доля протухших эталонов

Для практической работы с этой проблемой нужен измеримый показатель.

Gold Staleness Rate (доля протухших эталонов) — это процент вопросов в бенчмарке, для которых эталонный ответ перестал быть верным из-за изменений в базе данных (а не из-за ошибки в самом эталоне).

Формально: из всех эталонных пар «вопрос — правильный SQL» отбираются те, где запрос выполняется без синтаксических ошибок, но результат расходится с ожидаемым по причинам, связанным с эволюцией схемы.

Высокий GSR означает: бенчмарк устарел и требует ревалидации перед использованием. Использовать такой бенчмарк без проверки — значит оценивать системы по меркам прошлого, которые к настоящему не применимы.

Что это значит для систем работы с данными

Устаревание знаний о схеме — не проблема, которую можно решить один раз. Это постоянный процесс, требующий постоянного внимания.

Хорошая система работы с данными должна уметь:

Обнаруживать устаревание. Если запрос, который раньше работал, теперь возвращает ошибку или пустой результат — это сигнал. Не ошибка системы, а информация: что-то изменилось в схеме.

Адаптироваться к изменениям. Когда схема меняется, знания о ней должны обновляться. Не вручную, не по запросу — автоматически, при каждом изменении структуры.

Оценивать актуальность знаний. Не все знания одинаково свежи. Информация, извлечённая из запросов прошлого года, менее надёжна, чем информация из запросов прошлой недели. Это должно учитываться при построении ответов.

Парадокс накопленного знания

Здесь есть тонкое противоречие.

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

С другой стороны, запросы пятилетней давности отражают схему пятилетней давности. Если за эти пять лет схема изменилась — старые запросы кодируют устаревшие зависимости.

Решение: взвешивание по времени. Свежие запросы имеют больший вес в графе зависимостей, чем старые. Паттерны, которые устойчивы на протяжении нескольких лет, надёжнее тех, что появились только недавно или, наоборот, прекратились год назад.

Это превращает граф знаний из статичного объекта в живую систему, которая постепенно «забывает» устаревшее и «запоминает» новое.

Базы данных не забывают сами по себе — они просто меняются, не предупреждая тех, кто их изучил. Система, которая об этом знает, не просто строит знания — она следит за тем, когда эти знания перестают быть верными.