Обработка потока в 100 миллионов транзакций в сутки — это экстремальная инженерная задача, с которой сталкиваются при интеграции с промышленными системами, датчиками телеметрии (IoT), банковскими шлюзами и шинами очередей сообщений. Попытка решить такую задачу «в лоб» через стандартные механизмы и объекты 1С гарантированно приводит к отказу информационной базы. Разберем детально, с какими физическими ограничениями сталкивается платформа, почему сырой поток нельзя сохранять в 1С и как правильно выстроить масштабируемую архитектуру взаимодействия.
Фактическая пропускная способность: 100 млн событий в сутки при абсолютно равномерном распределении составляют около 1 160 операций в секунду (TPS). Однако на практике потоки телеметрии распределены неравномерно, а технологические пики увеличивают нагрузку до 3 000–10 000+ операций в секунду.
Темп роста хранилища: За 30 дней непрерывной работы таблица вырастает на 3 миллиарда записей, а за год — на 36,5 миллиардов. Реляционная база такого объема занимает десятки терабайт, что делает невозможными регламентные операции в рамках привычных технологических окон (реиндексация, обновление статистик СУБД, создание бэкапов).
Нагрузка на дисковую подсистему: Поточечная фиксация транзакций создает критическую утилизацию дисковых очередей (IOPS), вызывает стремительный рост журналов транзакций СУБД и постоянный сброс буферного пула.
Почему архитектура 1С не предназначена для записи сырых транзакций такого масштаба
Выясним причину, по которой объектная модель и реляционная структура платформы 1С не подходят для прямого сохранения входящих пакетов:
Отсутствие нативного массового импорта (Bulk Insert): Построчная запись через объекты метаданных платформы сопровождается проверками уникальности, вычислением ссылочной целостности и сериализацией. Даже вызов специализированных методов записи наборов данных в 1С генерирует на стороне СУБД значительно больше служебных операций, чем прямой потоковый бинарный импорт.
Разрастание системных индексов: Платформа 1С в обязательном порядке формирует кластерные и системные индексы (по ссылке, периоду, разделителям, номеру строки). Для аналитических и транзакционных таблиц соотношение размера индексов к полезным данным может достигать 10:1 и даже 20:1. При непрерывной записи сотен тысяч строк в минуту происходит постоянное расщепление страниц B-деревьев (page splits), деградация производительности и лавинообразное падение скорости записи.
Эскалация блокировок и дедлоки: При параллельной обработке потоков независимыми сеансами или фоновыми заданиями СУБД эскалирует построчные блокировки до уровня страниц и таблиц, что приводит к таймаутам ожидания и взаимным блокировкам (deadlocks).
Оптимальное решение: вынос первичной обработки и агрегации во внешнюю СУБД
Рассмотрим правильный архитектурный паттерн, применяемый на высоконагруженных проектах. Главное правило: сырые события никогда не должны попадать в оперативную базу 1С. Если первичные данные уже фиксируются во внешней СУБД (например, в Oracle, специализированных Time-Series или колоночных СУБД вроде ClickHouse), платформа 1С должна использоваться исключительно как аналитический и отчетный слой.
Разберем реализацию этой схемы по шагам:
Буферизация и очистка на внешнем уровне: Входящий поток транзакций от датчиков или шины принимается брокером сообщений и сбрасывается в специализированное аналитическое хранилище или исходную базу СУБД. На этом же уровне выполняется валидация формата и отсеивание поврежденных пакетов.
Агрегация данных до передачи в 1С: На стороне внешней СУБД регламентными процедурами или с помощью материализованных представлений формируются готовые срезы (поминутные, часовые, суточные) и регистрируются только контрольные инциденты (отклонения параметров от допустимых границ). Вместо 100 млн строк в сутки 1С получает от десятков тысяч до нескольких сотен тысяч компактных агрегированных записей.
Использование механизма «Внешние источники данных»: Для построения аналитических отчетов в 1С подключается внешняя таблица СУБД через объект конфигурации ВнешниеИсточникиДанных. Отчеты на базе системы компоновки данных (СКД) читают агрегаты напрямую из внешней базы, не расходуя дисковое пространство и транзакционные ресурсы основной базы 1С.
Механизм детализации (Drill-down): Если пользователю в отчете 1С требуется проанализировать исходную причину конкретного инцидента, система выполняет точечный параметрический запрос к внешней СУБД по идентификатору события и интервалу времени, отображая сырые строки без их постоянного сохранения в 1С.
Что делать, если часть данных обязательно нужно сохранять внутри 1С?
Если бизнес-логика строго требует сохранения определенных транзакций в базе 1С, необходимо минимизировать накладные расходы платформы. Разберем технические правила проектирования такого контура:
Отказ от объектных сущностей: Использование справочников и документов исключено. Единственный допустимый объект для высокоинтенсивной записи — независимый неподчиненный регистр сведений с минимально возможным количеством измерений и отключенным ведением итогов.
Пакетная вставка наборами записей: Запись выполняется строго пачками (оптимально от 5 000 до 20 000 строк в одном пакете) с явным указанием режима без предварительного чтения и без очистки существующих данных.
Посмотрим на пример корректной пакетной вставки данных в независимый регистр сведений:
НаборЗаписей = РегистрыСведений.ВходящийБуферТелеметрии.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.ИдентификаторПакета.Установить(ИдентификаторПакета, Истина);
Для Каждого СтрокаПакета Из МассивТранзакций Цикл
Запись = НаборЗаписей.Добавить();
Запись.Период = СтрокаПакета.Период;
Запись.ИдентификаторПакета = ИдентификаторПакета;
Запись.ИдентификаторДатчика = СтрокаПакета.ИдентификаторДатчика;
Запись.ЗначениеПараметра = СтрокаПакета.Значение;
КонецЦикла;
// Запись выполняется без замещения существующих данных, в единой транзакции
НаборЗаписей.Записать(Ложь);
Детерминированное шардирование потоков: При параллельной обработке пакетов через пул фоновых заданий (ФоновыеЗадания) каждый поток должен обрабатывать строго изолированный диапазон данных (например, по хэшу идентификатора источника). Это исключает блокировки одних и тех же страниц индексов в СУБД.
Секционирование (партиционирование) в СУБД: Таблица регистра сведений секционируется на уровне СУБД по суточным интервалам. Это позволяет мгновенно удалять устаревшие транзакции через отсечение партиций (DROP/TRUNCATE PARTITION), минуя тяжелые операции удаления строк через DELETE, создающие критическую нагрузку на журнал транзакций.
Таким образом, устойчивая работа системы при объеме в 100 миллионов событий в сутки достигается не наращиванием серверных мощностей 1С, а грамотным разделением контуров: потоковый прием и агрегация выносятся в специализированные базы данных, а 1С решает профильную задачу учетной аналитики и визуализации готовых показателей.