Предположим, вам нужно записывать много данных. Порядка 10 млн. записей разом.
Не часто, допустим, 1-2 раза в год.
Данные получаются как результат некоторого алгоритма на основании внешних данных.
Ваши действия?

Писать куда? в Null? Так он вроде и так туда быстро пишет

Для Каждого СтрокаТаблицы Из Таблица Цикл
Док.Заполнить(СтрокаТаблицы);
Док.Записать();
КонецЦикла;

(1) В 1С. допустим, в РС

(2) смело, оригинально

(3)
Для Каждого СтрокаТаблицы Из Таблица Цикл
МенеджерЗаписи.Заполнить(СтрокаТаблицы);
МенеджерЗаписи.Записать();
КонецЦикла;


Ты не прибедняйся, напиши подробней, што тебе надо

если нужна скорость то смотреть технологии bug date, если про 1с то писать напрямую в левую таблицу sql без блокировок

потом тащить медленно в регистр

(5) есть у меня некая маркенговая инфа.
По-сути, в пределе произведение товаров на контрагентов. И с пяток чиселок в каждом пересечении

Если пофиг на время - см. 5
Если надо быстрее, но в рамках ЛицСоглашения - то разбиваем данные по числу процессоров на сервере 1С - 1, и пишем фоновыми заданиями, внутри фонового - транзакция на 10000 записей.
Если не в рамках лиц соглашения - bulkinsert и смотрим, хватает ли диска. Если диска не хватает - секвестируем таблицу

Тех и других немного - в деле порядка 3-4 тыс. Но если умножить, будут миллионы

Ну и отключаем индексы, кроме кластерного.

(8) чем тебе ВИД не нравиться? На скуль из текстового файла грузиться быстро, а дальше цепляй таблицу и крути

(11) о! А вот это я попробую.

Куда маньяка дели? Он как раз на загрузки больших данных в РС собаку съел

(0)
1. Создать заранее в 1С 10 лямов пустых записей РС
2. Средствами SQL сделать напрямую UPDATE

(12) тем, что это все внутри 1С считается.
считается оно мухой, там элементарная арифметика.
но вот доходит до Записать() и можно идти ночевать.

csv

(17) это я читаю так: надо писать во внешний файл, а оттуда уже в базу?
Не уверен я, что в файл будет писать быстрее, чем в sql

Вот, кстати, тут на bcp батон крошат и ты можешь затестить схему
1С-> csv-> SQL
через эту утиль, но я не проверял.
https://habr.com/ru/post/536572/

(18) Будешь

1С в РС в кучу фоновых на сервере пишет достаточно быстро
Особенно если как правильно заметили без индексов лишних

(9) >разбиваем данные по числу процессоров на сервере 1С

не совсем правильно с точки зрения максимизации скорости
по числу процессоров надо бить если в базе активно работают
если же только эта задача грузит то надо задавать фоновых в 2-3 раза больше чем логических процессоров

(22) *надо = можно
на практике лучше тестами подбирать сколько фоновых под конкретный сервак
там особенности есть что пока одно фоновое ждет ответа от скуля, другое уже готовится и т.д.

(23) Пока одно ждет ответа от скуля, это ядро занято скулем.

(24) Совершенно не факт, там может быть ожидание дисковой в скуле и ядро по сути свободно

(0) выгружаем , загружаем . может проще хранимку на sql написать она перемножит две вьюхи , а результат сохранит в таблице sql , а потом это рещультат торжественно вывести в скд.

возможно даже без хранимки ado все это потянет

(18) а в чём вообще проблема?
Вот замер на файловой базе для записи 10 млн записей (2 измерения ссылка, 5 ресурсов Строка10)
Набор.Записать();    1    65,249991    27,77%
Набор.Загрузить(ТЗ);    1    47,858034    20,37%
ЗначениеВФайл(ИмяФайла, ТЗ);    1    29,283295    12,46%
ТЗ = РезультатЗапроса.Выгрузить();    1    25,161717    10,71%

Памяти конечно жрет, и на сервере одним набором писать не стоит. Но тупая внутренняя сериализация такой ТЗ - полминуты (файл 3GB)

(28) ЗаписатьВJson, не?

(29) да можно и JSON, можно и в csv. Понять не могу о чем тема

можно тупо по 100к записей в РС писать в один поток. РС же будет исходно пустой и историю предыдущую хранить не нужно?

(31) В несколько быстрее

(32) раз в полгода можно и подождать 10 минут.
А параллельно кстати можно писать без отбора?

Часто приходится писать большие объемы, обычно прямыми запросами пишем транзакциями по 10-50-100 тыс. записей, в зависимости от размера. Это самый быстрый вариант, в случае если по таблице есть итоги, пересчет идет сразу по большому количеству записей, что сокращает время расчета. Пересчеты итогов соответственно реализованы тоже прямыми запросами. Регистрация в обмен реализована аналогично прямыми запросами, но уже отдельными транзакциями. Если есть возможность разделить, то пишем в несколько потоков.

Если прямыми нет возможности, то отключаем индексы и грузим в режиме ОбменДанными.Загрузка = Истина, чтобы не было регистрации в обмен, это наиболее затратная часть. После записи уже регистрируем самостоятельно, если есть надобность.

(34) В 1С нельзя грузить транзакциями более 10000 записей, линейно растет время на работу менеджера управляемых блокировок в зависимости от количества записей в транзакции. Чертовы линейные переборы, они везде

я бы и хранил во внешней SQL базе.
а если арифметика действительно тривиальная а данные все равно внешние - то какой смысл их в 1с тянуть.
но если 1с все же нужна тогда грузим считаем и выгружаем обратно.

(11) отключаем = удаляем?

(36) из-за загрузки 12 раза в год? Костыли и лисапеды

(38) наоборот, избавление от лисапедов.
зачем изобретать механизмы быстрой записи, тратить место в базе, конфиг менять возможно.
если оно потом надо в 2 отчетах, которые манагер использует один раз в месяц.

(39) ты предлагаешь купить самолёт что-бы 1-2 раза в год летать на море... это и есть лисапед

(40) сделать микро скуль базенку из пары-тройки таблиц с тривиальной логикой = самолет? нуну))
это как раз адекватное решение которое позволит один раз его настроив забыть о нем на десятилетие.
а костыли пытаться делать что надо инструментом который не предназначен.
сегодня это 10млн записей
завтра поменяются требования к глубине аналитики и 10 млн превратятся в 200 млн легко.
мы вернемся туда же изобретать новые костыли и механизмы обхода ограничений 1с.

либо добавим новую табличку в скуле и доп параметр в обработку которая с этими таблицами скуля работает - дело 10 минут.

К сожалению, 1С не умеет бвстро писать в свою базу. Ограничения архитектуры.

Если 1-2 раза в год, но производительность записи не критична, мо-моему.
Если все же критична, то я бы писал в отдельную базу, а читал через ВИД.

(16) >там элементарная арифметика

Тогда и посчитать можно во внешней базе или при загрузке.

(42) "но" -> "то"

(42) нужно понимать где границы "быстро" и "ограничений архитектуры".
Если взять типовые периодические регистры обвешанные планами обмена, то задача ТС может уйти за эти границы.

А для простого непериодического регистра замер на файловой базе в (28). Запись набора 10 млн - чуть больше минуты. Ну пусть на сервере и частями будет - 10 минут.

(42) Никаких ВИД!
Другие средства использовать

Но да внешнее решение и не тянуть это в 1С

Была подобная трабла у Мани в его ГигаРазработке вроде
Короче нужные данные и/или некие "правила" из 1С наружу выкидываем и там снаружи пусть все считается
А какие конкретно технологии выбрать это уже вкусовщина и знания

(45) (46) а 1С тебе зачем?

(47) Удобный/привычный интерфейс для юзеров

(48)+ Имхо еще бы в динамический список можно было результата http запроса подсовывать и было бы супер

(49) ну так храни в базе и никаких проблем.

(3) Разве НаборЗаписей долго пишет?
Если нужно именно добавить записи, то делаем в РС доп.измерение "ДопКлюч". И пишем новые записи блоками по 500 тыс. через Набор.Записать(). Для каждого набора указываем свой "ДопКлюч", чтобы они не затирали друг друга. И удалять так будет проще.

(35) в 1С и не пишем такими транзакциями, речь шла о прямых запросах

(13) Еще использование итогов у регистра отключи, перед началом обработки. Когда запись закончится надо будет включить. Так у тебя пересчеты не будут выполняться для каждого записанного набора, а в конце они пересчитаются одним махом.