Данные и Конфигурация

Очевидным вещам будет посвящен этот пост, и я бы никогда не написал его, если бы не наболело...

Существует масса систем представляющие собой front-end в виде некого сервера приложения и back-end, в роли которого, как правило, выступает база данных. Практически всегда все записи в базе данных можно подразделить, как минимум, на два класса: Даные и Конфигурации. Под Конфигурациями я здесь понимаю набор данных, записей базы данных, необходимых для функционирования приложения и выполнения им поставленных перед ним задач с заданными параметрами качества, производительности и т.п. Под Данными я понимаю те записи базы данных для обработки и хранения которых, собственно, была разработанна система. Т.е, чтобы совсем все упростить, Конфигурация - нужна Системе, чтобы работать так, как это требует пользователь, Данные - нужны пользователю.

Возьмем, для примера, систему управления сенсорами IDS. Здесь Конфигурацией будут данные, представляющие собой, в частности, политики обнаружения сенсоров, их параметры работы (какой интерфейс используется для мониторинга трафика, какой для управления, какие у них IP-адреса, пр), пользовательские оповещения с системы управления (кому, от кого и через что слать почту, куда слать трапы SNMP), пр. К данным мы отнесем журналы, которые генерят сенсоры и складывают в базу, чтобы потом пользователь в них что-то искал и строил причудливые отчеты. По подобному принципу построена масса систем: системы Web-фильтрации, Антивирусные комплексы предприятия, различные системы контроля доступа к чему-либо, пр.

Несмотря на широкое распространение подобной архитектуры, почему-то только единицы производителей догадываются хранить Данные отдельно от Конфигурации! Как правило, и то и другое помещаются в одну базу данных, и не предоставляется удобных интерфейсов для выделения из этой "общественной помойки" только, например, Конфигурации. Складывается впечатление, что необходимость такого выделения не очевидна. Что ж, попробую привести аргументы в пользу такого выделения.

1. Основное. Раздельное хранение Данных и Конфигурации позволит выполнять быстрое резервное копирование и восстановление Конфигурации в случае сбоя. Очевидно, что в системах сбора и анализа логов Конфигураций в тысячи раз меньше чем Данных, и в случае, если потеря Данных значительно менее критичное событие, чем потеря системы (ну например, система используется, главным образом, как средство оперативной готовности, а не как система для долгого архивирования и хранения Данных), куда более разумно выполнять резервное копирование только Конфигурации, что значительно быстрее и занимает меньше места.

2. Развивая далее идею различных требований к Конфигурации и Данным, в случае, если данных очень много и они маловажны, - их можно хранить, например, на RAID0, тогда как Конфигурации - на RAID1. Это позволит обеспечивать требования к Системе и, вместе с тем, экономно использовать дисковое пространство.

3. Раздельное хранение позволит выполнять быстрое удаление Данных, если их количество вышло из-под контроля. Всем известно, что TRUNCATE TABLE работает значительно быстрее чем обычный DELETE, а в совсем тяжелом случае можно и DROP TABLE.

4. В случае специфических требований к Данным, например, их обязательного шифрования, это можно будет реализовать не затронув Конфигурацию.

5. Можно без нарушения конфиденциальности данных отдавать базу Конфигурации в поддержку производителя на анализ, чтобы тот мог с чем-то помочь.

6. ... и т.д. Есть хорошее правило: разделять данные, требования (не важно какие: конфиденциальность, целостность, доступность или все вместе) к которым различны. К Данным и Конфигурации в большинстве случаев требования сильно различны.

Вообще, во всех книжках по IIS написано, что не надо располагать файлы Web-приложений на системном диске (где стоит Windows), в книжках по СУБД упоминается, что файлы данных также не стоит хранить на системном диске... Проблема одна и та же: разделение Конфигурации от Данных. Но почему практически никто из производителей не хранит Конфигурации и Данные в разных базах данных. Может, на то есть неведомые мне причины?
В случае хранения Конфигурации и Данных в разных базах данных, можно пойти дальше и хранить их и в разных СУБД, что значительно повысит надежность системы, простоту ее восстановления и обслуживания.