Как распределить данные одной базы 1С по разным серверам и возможно ли использовать секционирование таблиц в СУБД?

В крупных и высоконагруженных информационных системах на базе платформы «1С:Предприятие» администраторы и архитекторы баз данных часто сталкиваются с необходимостью оптимизации хранения больших объемов информации. Иногда от бизнеса или руководства поступают весьма нестандартные задачи. Например: физически разнести данные одной таблицы на разные серверы (горизонтальное и вертикальное секционирование) и обеспечить возможность «горячего» отключения одного из серверов так, чтобы остальная часть системы продолжала функционировать.

В этой статье мы подробно разберем, насколько реализуема подобная задача средствами СУБД (на примере MS SQL Server и PostgreSQL), с какими критическими ограничениями платформы 1С вы столкнетесь при попытке внедрить секционирование вручную, и какие существуют надежные альтернативные архитектурные решения.

---

Суть проблемы: Чего хочет заказчик и как это видит СУБД

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

Для СУБД (будь то MS SQL Server, Oracle или PostgreSQL) база данных «1С:Предприятие» представляет собой стандартный набор таблиц с индексами. Однако платформа 1С накладывает жесточайшие ограничения на структуру этих таблиц, их связи и логику работы с ними. Попытка внедрить низкоуровневые механизмы секционирования напрямую через СУБД в обход платформы 1С неизбежно приводит к ряду серьезных проблем.

---

Критические ограничения СУБД и платформы 1С при секционировании

Рассмотрим подробнее технические препятствия, которые делают прямое секционирование одной таблицы 1С по разным физическим серверам практически невозможным в реальной эксплуатации.

1. Требование к первичному ключу (Clustered Index / Primary Key)

Чтобы СУБД понимала, в какую секцию (партицию) записывать конкретную строку, столбец секционирования (например, дата документа или идентификатор организации) должен быть частью первичного кластерного ключа таблицы. В 1С структура таблиц и их индексы жестко контролируются платформой. Мы не можем произвольно изменить первичный ключ таблицы (например, добавить туда реквизит организации) на стороне СУБД. Любое ручное изменение структуры индексов через SQL Management Studio приведет к тому, что платформа 1С потеряет возможность корректно работать с объектами метаданных.

2. Проблема реструктуризации таблиц при обновлениях

Платформа 1С регулярно выполняет реструктуризацию таблиц при обновлении конфигурации или изменении свойств объектов. Этот процесс происходит по следующему алгоритму:

1. Платформа создает временную таблицу с именем вида _v8_tmp_X.
2. Переносит туда все данные из исходной таблицы.
3. Удаляет старую таблицу.
4. Переименовывает временную таблицу в рабочую и заново строит индексы.

Любые ваши настройки секционирования, распределенные представления (Views), триггеры и схемы разбиения на стороне СУБД будут мгновенно уничтожены при первой же реструктуризации измененного объекта метаданных.

3. Нарушение ссылочной целостности и аварийный режим базы данных

Выясним, что произойдет при попытке физического отключения сервера, на котором хранится одна из секций таблицы. Объектная модель 1С спроектирована как единое целое. Если база данных физически распределена по разным файлам или серверам на уровне СУБД, потеря доступа хотя бы к одному файлу или связанному серверу (Linked Server) приведет к тому, что СУБД переведет всю базу данных в аварийный режим (например, SUSPECT или RECOVERY_PENDING в MS SQL Server). СУБД просто не позволит запустить базу «частично», так как нарушается физическая и логическая целостность транзакционной модели.

---

Технология Distributed Partitioned Views (DPV) в MS SQL Server

Теоретически в MS SQL Server распределение одной таблицы по разным физическим серверам реализуется через механизм **распределенных секционированных представлений** (Distributed Partitioned Views — DPV) с использованием связанных серверов (Linked Servers). Разберем, как это работает на бумаге:

-- Пример логики создания распределенного представления на уровне СУБД
CREATE VIEW dbo.v_SalesData AS
SELECT * FROM Server1.SalesDB.dbo.SalesTable WHERE RegionID = 1
UNION ALL
SELECT * FROM Server2.SalesDB.dbo.SalesTable WHERE RegionID = 2;

Хотя этот механизм существует, для систем на платформе 1С он абсолютно не применим по следующим причинам:

• Огромные задержки на сетевое взаимодействие: Любой запрос на чтение или запись, проходящий через Linked Servers, требует координации распределенных транзакций через службу координатора распределенных транзакций (MS DTC). Это вызывает катастрофическое падение производительности в OLTP-системах, какой и является 1С.
• Непредсказуемость планов запросов: Оптимизатор СУБД часто ошибается при построении планов запросов, проходящих через распределенные представления, что приводит к избыточному сканированию таблиц на удаленных серверах и взаимоблокировкам (deadlocks).

---

Рабочие альтернативные решения архитектуры 1С

Если перед вами стоит задача распределить данные по разным физическим серверам или обеспечить безопасность и отказоустойчивость, рассмотрим проверенные на практике и поддерживаемые платформой 1С методы.

Решение 1. Распределенные информационные базы (РИБ)

Если вам требуется физически разделить данные по серверам (например, по филиалам или организациям) так, чтобы при отключении одного сервера остальные продолжали бесперебойную работу, используйте штатный механизм РИБ.

Рассмотрим этот подход по шагам:

1. Настраивается центральная база и периферийные узлы РИБ на разных физических серверах.
2. В правилах синхронизации настраивается фильтрация данных (например, в филиал отправляются только его документы и справочники).
3. В случае аварии или экстренной необходимости отключения одного из филиалов, вы просто прекращаете обмен. При этом центральный офис и другие филиалы продолжают полноценную работу, так как их базы данных полностью автономны.

Решение 2. Вынос таблиц и индексов на разные диски (Файловые группы)

Если цель секционирования — повысить производительность дисковой подсистемы и разнести «горячие» и «холодные» данные, это можно сделать в рамках одного сервера СУБД с помощью файловых групп.

Проанализируем этот сценарий:

• В MS SQL Server создаются дополнительные файловые группы на быстрых (SSD/NVMe) и медленных (HDD/SATA) дисках.
• Тяжелые таблицы (например, версионирование объектов, присоединенные файлы или старые регистры) переносятся в отдельную файловую группу на медленный диск.
• Индексы и оперативные таблицы остаются на быстрых накопителях. Для платформы 1С база остается единым логическим целым, но физически нагрузка на диски распределяется оптимально.

Решение 3. Использование современных возможностей Postgres Pro Enterprise для 1С

Если ваша инфраструктура работает на СУБД PostgreSQL, обратите внимание на коммерческую версию Postgres Pro Enterprise, разработанную специально для крупных инсталляций 1С. В ней реализованы механизмы, позволяющие гибко управлять хранением данных без нарушения логики 1С:

• Секционирование по ссылке (Reference Partitioning): Позволяет автоматически секционировать дочерние (зависимые) таблицы на основе внешнего ключа к родительской таблице, что решает проблему целостности связанных данных в 1С.
• Управление жизненным циклом информации (pgpro_ilm): Позволяет автоматически перемещать исторические или архивные секции таблиц на дешевые дисковые массивы по расписанию, оставляя актуальные данные на производительном оборудовании. При этом база для платформы 1С выглядит как единая таблица.

Решение 4. Штатный механизм платформы «Работа с копиями баз данных»

Начиная с версии платформы 8.3.14, в 1С встроен официальный инструмент для разделения нагрузки между серверами СУБД. Если ваша цель — снизить нагрузку на основной рабочий сервер СУБД за счет вынесения тяжелых аналитических отчетов на другой физический сервер, выполните следующие действия:

1. Настройте стандартную репликацию на уровне СУБД (например, *AlwaysOn* в MS SQL Server или потоковую репликацию в PostgreSQL) с основного сервера на резервный.
2. В конфигураторе или режиме «1С:Предприятие» настройте параметры работы с копиями баз данных.
3. Укажите, какие именно отчеты, запросы или объекты должны считывать данные из копии. Платформа 1С будет автоматически перенаправлять запросы на чтение на второй физический сервер, снижая нагрузку на основную транзакционную базу.

Решение 5. Сценарии безопасности («Экстренное отключение»)

Если клиент просит возможность «дернуть шнурочек» и скрыть конфиденциальные данные, физическое секционирование СУБД здесь не поможет, так как база просто сломается. В таких случаях применяются другие методы:

• Хранение конфиденциальных данных во внешних источниках: Все секретные файлы, сканы или конфиденциальные реестры хранятся во внешней СУБД или на отдельном сетевом томе (например, шифрованном каталоге BitLocker / VeraCrypt). В самой 1С хранятся только ссылки на эти файлы. При отключении шифрованного тома или сетевого пути платформа продолжит работать со стандартными учетными данными, но доступ к секретным файлам будет мгновенно заблокирован.
• Использование проприетарного промежуточного ПО (Middleware): Компании-интеграторы (например, Softpoint) предлагают специализированные драйверы и брокеры запросов, которые могут перехватывать SQL-запросы от сервера приложений 1С к СУБД и динамически распределять нагрузку или блокировать доступ к определенным сегментам данных по команде администратора.

---

Подведем итоги

Попытка реализовать распределенное горизонтальное или вертикальное секционирование одной таблицы 1С по разным серверам средствами СУБД — это крайне рискованный путь, который сделает вашу базу необновляемой, нестабильной и приведет к постоянным ошибкам СУБД. При первом же обновлении конфигурации платформа сотрет все ручные настройки схем секционирования.

Для решения задач масштабирования и безопасности используйте только стандартные, поддерживаемые вендором архитектурные паттерны: механизмы РИБ, интеграцию через шины данных (RabbitMQ/Kafka), вынос тяжелых данных во внешние файловые хранилища или штатный механизм «Отчеты на копиях БД».