Быстрый перенос регистров между базами 1С: своё расширение вместо XML-обмена
Штатный обмен 1С (планы обмена, выгрузка через XML/XDTO) универсален и потому медленный: построчная сериализация в текст, оверхед на разбор схемы, одна нитка. Когда базы разные — это оправдано. Но когда нужно перелить миллионы строк регистров между базами с идентичной конфигурацией (клон-синк, наполнение тестового контура с боевого, перенос архива движений), платить за эту универсальность гигабайтами XML и минутами ожидания незачем.
Инструмент делает проще: раз конфигурации совпадают — наборы записей пишутся во внутренний бинарный формат платформы (ЗначениеВФайл) порциями-чанками, рядом кладётся manifest.json, и на приёмнике всё грузится замещением по регистратору. Никакой построчной сериализации в текст. Поставка — расширение конфигурации (AddOn, 6 объектов метаданных, ноль зависимостей от базовой конфы): дропается в любую конфигурацию, включая БСП-релизы, без правки основной.
Что умеет
- Бинарные чанки +
manifest.json. Набор режется на порции, каждая пишется однимЗначениеВФайл; манифест хранит состав, версию, формат, сжатие и отбор — загрузка самодостаточна по манифесту. - Параллельная выгрузка и загрузка фоновыми заданиями. Запуск адаптивный: есть БСП — через
ОбщегоНазначения.ВыполнитьМетодКонфигурации, нет — через собственный тонкий шим; отдельное ветвление для файловой и клиент-серверной ИБ. - Портативный JSON-формат чанков (
СериализаторXDTOс явным назначением типов) — переживает смену версии платформы, когда.binуже нельзя. - Опциональное сжатие deflate — ~15% исходного размера ценой ~×1,3 по времени; для передачи по сети выгодно, для локального клон-синка — нет.
- Отбор по периоду для РН/РБ и периодических РС (с защитой от смешивания периодических и непериодических регистров в одной выгрузке).
- Живой прогресс с отменой и докачкой после обрыва (уже загруженные чанки пропускаются по sidecar-файлу).
- Профили СУБД (файловая / MS SQL / PostgreSQL) сами подбирают размер чанка и число потоков под приёмник.
- Метрики OpenMetrics (
.prom) рядом с отчётами — подключается к Grafana черезnode_exporter. - Транспорт через RabbitMQ (PoC): «папка → очередь → папка», ack после записи файла, валидация имени файла из очереди (защита от path traversal).
- Встроенный самотест — план прогона с пресетами: сборочные тесты корректности (в т.ч. потеря данных в подчинённых регистрах, path traversal, отмена/зомби-воркеры) и бенчмарки со сводным HTML-отчётом.
Сколько это в цифрах
Регистр сведений, синтетика ~160 байт/строку. Два стенда — файловая ИБ на NVMe и MS SQL Server на SSD.
| Сценарий | Результат |
|---|---|
| Round-trip 5 млн строк (bin / deflate / json) | 1:1, сверка байт-в-байт |
| Выгрузка, MS SQL, 8 потоков | 241 000 строк/с (×4,72 к одному потоку) |
| Загрузка, MS SQL, 8 потоков | 72 800 строк/с (×4,24) — на серверной СУБД параллелится и запись |
| Выгрузка, файловая ИБ, 8 потоков | 208 000 строк/с (×2,2; плато после ~4 потоков — упор в СУБД) |
| Сжатие deflate=9 | 14,8% исходного размера (151,5 → 22,4 МБ на 1 млн строк) |
На файловой ИБ запись упирается в монопольную блокировку .1CD (загрузка масштабируется лишь до ×1,25) — серверная СУБД снимает этот потолок. Дефолты (размер чанка, число потоков, режим сжатия) подобраны по замерам, не по наитию: «теоретически правильная» балансировка через полную сортировку однажды уронила параллелизм с ×1,70 до ×1,06 — с тех пор любая перф-правка только с бенчмарком до/после.
Как пользоваться
- Подключить
.cfeк обеим базам и снять «Безопасный режим» / «Защиту от опасных действий» (движку нужен файловый I/O). - В источнике: выбрать регистры чек-листом, указать папку обмена, при необходимости — формат/сжатие/потоки/период → «Выгрузить».
- Перенести папку на приёмник (или указать общую) → в приёмнике «Загрузить».
Для переноса между разными версиями платформы — переключить формат на JSON. Профиль СУБД приёмника подберёт остальное.
Ограничения
- Только идентичные конфигурации: GUID-ссылки между разными базами не транслируются (клон, копия, синхронизированные справочники). Маппинг ссылок — отдельная задача, инструмент её не решает.
.bin— внутренний формат платформы: чувствителен к версии платформы и метаданным. Для устойчивости — JSON.- Загрузка по умолчанию однопоточная (параллелится в первую очередь выгрузка); на файловой ИБ параллелизм выгрузки выходит на плато после ~4 потоков.
- Расширение исполняется доверенным кодом от
rphost— встроена валидация пути папки обмена.
Где взять
Исходники, собранный .cfe, документация и бенчмарки — в открытом репозитории (MIT): https://github.com/ohmyfcingod/fast-register-transfer-1c
P.S. Присмотритесь к скриншотам вкладки «Тесты». В типовых 1С-формах такое обычно не водится; что именно — оставим сюрпризом. 🙂
Вступайте в нашу телеграмм-группу Инфостарт