Электронный архив — это не просто хранилище файлов‚ а сложная информационная система‚ обеспечивающая долговременное хранение‚ поиск‚ доступ и юридическую значимость документов. В центре любой такой системы находится база данных (БД)‚ которая выполняет роль «мозгового центра»‚ управляющего метаданными‚ связями‚ версиями и процессами жизненного цикла документов. Грамотное ведение этой базы данных — залог надежности‚ скорости и соответствия архива нормативным требованиям (ГОСТ Р 7.0.99-2018‚ ISO 14721‚ ISO 16363‚ 152-ФЗ и др.).

Архитектурная роль базы данных в электронном архиве

В современных системах электронного архивирования (SEA) используется разделение хранилищ:

• Файловое хранилище (Content Store): Хранит сами бинарные объекты (файлы документов), PDF/A‚ TIFF‚ XML‚ видео‚ аудио. Обычно это объектные хранилища (S3‚ MinIO‚ Ceph) или кластерные файловые системы с дедупликацией и контрольными суммами.
• База данных метаданных (Metadata Database): Хранит структурированную информацию о документах: атрибуты (автор‚ дата‚ тип‚ номер)‚ классификационные коды‚ права доступа‚ историю действий (аудит)‚ связи между документами (дело‚ том‚ версия)‚ технические метаданные (хеш-суммы‚ формат‚ размер).

Ключевой принцип: Файлы в хранилище неизменяемы (WORM — Write Once‚ Read Many). Все изменения состояния документа (перемещение‚ аннулирование‚ изменение прав‚ версионирование) фиксируются только в базе данных.

Выбор СУБД: Реляционные vs NoSQL vs NewSQL

Выбор системы управления базами данных (СУБД) определяет масштабируемость и функциональность архива.

Реляционные СУБД (PostgreSQL‚ Oracle‚ MS SQL Server‚ MySQL)

Наиболее частый выбор для корпоративных и госархивов.

• ACID-транзакции: Гарантия целостности при сложных операциях (например‚ формирование дела из 100 документов — атомарная операция).
• Строгая схема: Соответствует жесткой структуре архивных описей (фонд‚ опись‚ дело‚ документ).
• JSON/JSONB поддержка (PostgreSQL): Позволяет хранить гибкие‚ нетипизированные метаданные (схемы Dublin Core‚ EAD‚ произвольные атрибуты карточки документа) без потери производительности SQL-запросов.
• Партиционирование таблиц: Критично для таблиц аудита (логи) и версий документов (партиционирование по дате/годам).

NoSQL (MongoDB‚ Cassandra‚ Elasticsearch как основное хранилище)

• Подходят для архивов с экстремально высокой нагрузкой на запись (миллионы документов в сутки) и неструктурированными схемами метаданных.
• Риски: Сложность обеспечения строгой консистентности (eventual consistency недопустима для юридически значимых операций)‚ сложность построения иерархических отчетов (деревья дел).

Гибридный подход (Best Practice)

1. Основная БД (PostgreSQL/Oracle): Метаданные‚ структура архива‚ права‚ аудит‚ версии — всё‚ что требует ACID.
2. Поисковый движок (Elasticsearch / OpenSearch): Асинхронная репликация данных для полнотекстового поиска‚ фасетной навигации‚ аналитики.
3. Кэш (Redis): Сессии пользователей‚ временные корзины‚ очереди задач на конвертацию/индексацию.

Модель данных: Ключевые сущности и связи

Правильная нормализация схемы БД предотвращает аномалии обновления и обеспечивает быстрые выборки.

Основные таблицы (упрощенно):

Обеспечение целостности и неизменяемости (Immutability)

Это главное отличие архивной БД от операционной (OLTP).

Контроль целостности на уровне БД

• Триггеры (Triggers): Запрет UPDATE и DELETE для таблиц FileVersions‚ AuditLog‚ Documents (кроме статусов/прав). Только INSERT.
• Внешние ключи (Foreign Keys): Строгое соблюдение ссылочной целостности (документ не может существовать без дела‚ версия — без документа).
• CHECK-constraints: Валидация форматов дат‚ номеров‚ хешей (например‚ длина SHA-256 = 64 hex chars).

Криптографическая привязка (Fixity)

При добавлении версии файла в БД обязательно записывается хеш-сумма (SHA-256/512).

• Периодические фоновые задачи (pg_cron‚ pgAgent‚ внешний шедулер) пересчитывают хеши файлов в объектном хранилище и сравнивают с БД.
• При несовпадении — генерация инцидента (ALERT) и блокировка доступа к поврежденному объекту.

Блокчейн / Merkle Trees (продвинутый уровень)

Для максимального доверия (например‚ в госархивах‚ нотариате) хеши записей аудита или корневые хеши Меркле-деревьев периодически анкоринговятся во внешнюю блокчейн-систему или подписываются КЭП (Квалифицированной Электронной Подписью) ответственного лица.

Управление жизненным циклом и сроками хранения

База данных — исполнитель механизма Retention Policy (Политики хранения).

Механика реализации:

1. Справочник RetentionRules: Привязка к классификатору (код номенклатуры) -> Срок хранения (лет) -> Действие по истечении (Уничтожение / Передача в госархив / Продление / Переоценка).
2. Вычисляемое поле (или материализованное представление) DispositionDate у документа/дела: RegDate + RetentionPeriod.
3. Ежедневный джоб (Job) сканирует дела с Status='Closed' AND DispositionDate <= CURRENT_DATE.
4. Формируется Акт экспертизы/уничтожения (документ в том же архиве)‚ требуется ЭП экспертов/руководителя.
5. При подтверждении: обновление статуса дела‚ физическое удаление файлов из объектного хранилища (по списку ID из БД)‚ запись в Аудит.

Производительность и масштабирование

Индексирование

• B-Tree: Первичные ключи‚ внешние ключи (CaseID‚ DocumentID)‚ даты регистрации‚ номера.
• GIN / GiST (PostgreSQL): Для JSONB-атрибутов (гибкие метаданные)‚ полнотекстового поиска (tsvector)‚ массивов тегов.
• Partial Indexes: CREATE INDEX idx_docs_active ON documents(case_id) WHERE status != 'Deleted';, экономит место и ускоряет частые выборки.

Партиционирование (Partitioning)

Обязательно для больших таблиц (AuditLog‚ FileVersions‚ SearchIndexQueue).

• Range Partitioning по дате: Месячные/годовые секции. Позволяет мгновенно отбрасывать старые секции (DETACH PARTITION) при архивации логов в холодное хранилище.
• List Partitioning по FondID/DepartmentID: Для мультиарендности (SaaS-архивы) — изоляция данных клиентов на физическом уровне.

Репликация и HA (High Availability)

• Синхронная репликация (Sync Replication): Для основной БД — гарантия RPO=0 (нулевая потеря данных). Минимум 1 Master + 1 Sync Standby.
• Асинхронные реплики (Async Read Replicas): Для отчетов‚ аналитики‚ бэкапов‚ поискового индексатора — снятие нагрузки с мастера.
• Connection Pooling (PgBouncer / ProxySQL): Обязательно для обработки тысяч соединений от микросервисов архива.

Миграция схемы (Schema Migrations)

Архив живет десятилетиями. Схема БД эволюционирует.

• Использование инструментов миграций (Flyway‚ Liquibase‚ Goose‚ golang-migrate).
• Каждая миграция — версия‚ откат (down)‚ идемпотентность.
• Правило: Никогда не удаляем колонки/таблицы сразу. Помечаем DEPRECATED‚ убираем из кода приложения‚ удаляем через 2-3 мажорные версии.
• Тестирование миграций на копии продакшн-данных (анонимизированных) в CI/CD пайплайне.

Безопасность и соответствие 152-ФЗ / GDPR

Шифрование

• TDE (Transparent Data Encryption): Шифрование файлов данных на диске (PostgreSQL, через файловую систему LUKS/ZFS encryption или расширения; Oracle/MS SQL — нативно).
• Column-level Encryption: Для ПДн (паспорт‚ СНИЛС‚ мед. данные) — шифрование отдельных колонок ключами‚ управляемыми HSM/KMS (HashiCorp Vault‚ AWS KMS‚ Яндекс KMS). Приложение расшифровывает только при необходимости отображения.

Аудит доступа к БД (Database Activity Monitoring — DAM)

• Логирование всех запросов к чувствительным таблицам (SELECT * FROM documents WHERE ...).
• Интеграция с SIEM (Splunk‚ ELK‚ Positive Technologies MaxPatrol SIEM).
• Разделение ролей БД: app_user (только DML через процедуры/ORM)‚ admin_user (DDL‚ миграции)‚ readonly_report (только SELECT для BI).

Анонимизация для тестов

Автоматизированные скрипты для создания дампов dev/staging сред с заменой ПДн на синтетические данные (Faker)‚ сохраняющие распределение и длину строк для корректности планов запросов.

Резервное копирование и Disaster Recovery (DR)

Правило 3-2-1: 3 копии данных‚ на 2 разных носителях‚ 1 копия в другом географическом регионе (Geo-redundancy).

Интеграция с внешними системами (API / ESB)

База данных не должна быть «черным ящиком»‚ доступным только приложению архива.

• CDC (Change Data Capture): Debezium (Kafka Connect) читает WAL и публикует события изменений (DocumentCreated‚ CaseClosed‚ AccessGranted) в Kafka / RabbitMQ. Это основа Event-Driven Architecture для интеграции с 1С‚ ERP‚ CRM‚ Системами управления процессами (BPM).
• API Gateway: Предоставляет REST/gRPC/GraphQL интерфейсы. Прямые SELECT'ы из внешних систем запрещены.
• Федеративный поиск: Выдача метаданных в протоколы OAI-PMH‚ SRU/CQL‚ IIIF для агрегаторов (Научная библиотека‚ Архивные порталы).

1. [ ] Используется PostgreSQL (или Oracle/MS SQL) с включенным WAL-архивированием и PITR.
2. [ ] Схема БД версионируется (Flyway/Liquibase)‚ миграции проходят Code Review.
3. [ ] Таблицы аудита и версий партиционированы по времени.
4. [ ] Хеш-суммы (SHA-256) файлов хранятся в БД и верифицируются регулярно (Fixity Check).
5. [ ] Триггеры/Constraints запрещают изменение истории (Immutability Pattern).
6. [ ] Реализована политика хранения (Retention) с автоматическим формированием актов.
7. [ ] Настроена синхронная репликация (RPO=0) и геораспределенный бэкап.
8. [ ] ПДн зашифрованы на уровне колонок/диска‚ доступ к БД аудируется (DAM/SIEM).
9. [ ] Внедрена CDC (Debezium) для интеграций без прямого доступа к БД.
10. [ ] Проводится регулярное тестирование восстановления (DR Drill) раз в квартал.

Ведение базы данных электронного архива, это инженерная дисциплина на стыке архивоведения‚ администрирования БД‚ информационной безопасности и DevOps. Инвестиции в правильную архитектуру БД на старте экономят порядки ресурсов на этапе эксплуатации‚ масштабирования и прохождения аудитов (ФСТЭК‚ ФСБ‚ Росархив‚ ISO).