Здравия!
Недавно нарисовалась такая задачка. Хочется попросить помощи сообщества в её решении.
Допустим, есть большая, сложно организованная и запутанно функционирующая система. С достаточно нетривиальной ценой изменения ввиду долгой истории развития. Использующая кучу алгоритмов и разноплановых данных. Объёмом многие миллионы строк кода. На С++.
В качестве одной из подсистем в этой системе живёт и здравствует подсистема так называемых метаданных (далее — просто МД). МД — это объекты, обеспечивающие вспомогательную информационную поддержку внутренних алгоритмов (да, даже так) и структур данных. Для отображения в ГУИ, для транслирования в другие форматы... да я толком и сам не очень знаю, для чего ещё. Много для чего. Полезная это штука — метаданные.
Для МД существует набор алгоритмов, которые чего-то с ними как-то делают. Понятно, что нежелательно вносить правки, способные повлиять на алгоритмы работы с МД.
И вот выяснилось, что с определённого момента дерево МД занимает в памяти много места. При этом используются далеко не все, многие просто висят в памяти потому, что кто-то когда-то их зачем-то загрузил. И появилось желание соптимизировать их по объёму.
Из того, что мне уже известно, можно перечислить следующее:
— есть единый базовый интерфейс всех типов МД
— самих типов МД много (порядка нескольких сотен)
— метаданные могут содержать сколь угодно вложенные ссылки на другие метаданные
— метаданные частенько хранятся другими метаданными в контейнерах типа мап, хэшмап (как завёрнутые в смарт-пойнтеры, так и не завёрнутые)
— МД умеют себя загружать из и сохранять в хранилище встроенными средствами сериализации
— изначально дерево МД пусто; объекты появляются там:
а) либо по запросу внешнего кода (десериализуются из хранилища) и никогда из памяти не удаляются
б) либо путём построения нового дерева "с нуля" средствами new (ручная сборка) для дальнейшей сериализации
— при загрузке также загружаются все зависимые МД (которых может быть весьма много)
— я не знаю, есть ли, возможно ли и разрешены ли закольцованные ссылки на метаданные (это ещё предстоит установить экспериментально)
— каждый тип МД волен выбирать каких и сколько данных иметь и какие операции с ними и с внешним миром производить (никаких контрактных ограничений не замечено)

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

У меня появилась одна простая, в сущности, идея: обязать каждый тип МД (их много, но не так, как внешнего кода) все свои свойства держать в отдельно выделенной структуре (навроде pImpl), для этих структур написать алгоритм отслеживания обращений и "сборки мусора" (то бишь сериализации устаревших), а сами типы МД использовать в качестве фасадов к этим pImpl. Однако, возможно, появится дельный коммент, который изменит мой взгляд на проблему. Приветствуется всё: замечания, предложения, ссылки на аналогичные, реализованные кем-то где-то, алгоритмы (что уж тут говорить — воспользоваться опытом проще, чем этот опыт наработать).

Спасибо, уважаемые коллеги.

Модераторам: я толком не разобрался, в каком форуме более подходяще было бы размещать данный пост. Он подходит и для алгоритмов, и для архитектуры, и для прикладных вопросов. Прошу помочь с позиционированием если что не так