в базе 1с 700.000 номенклатуры.
Во второй базе 4.500.000 номенклатуры

Проверяю по артиклу есть ли в первой базе позиция и если нет кидаю ее из второй базы. большей части нету поэтому расчеты примерно такие
В среднем за 1 секунду, вижу что создается 5-7 новых позиций.

4.500.000 /7 = 642 857 секунд

Это получается 7.5 суток.  При этом надо надеется что за 7.5 суток не знаю свет не вырубится на долго (есть бесперебойник минут на 30-40 хватает). или не знаю мало ли что сервер ребутнется/зависнет и т.д.
Есть какие то мысли как ускорить загрузку (кроме как купить еще более новый сервер))

(0) чтоб свет не влиял переноси через план обмена

Можно ускорить сделав обмен многопоточным

(4) да свет это к слову так на всякий случай

https://infostart.ru/public/306865/

(7) в этом примере идет через  ТаблицаТоваров = Запрос.Выполнить().Выгрузить();

я че то сыкую 4.5 миллиона позиций с данными и т.д. выгружать сразу...

у меня через Выполнить().Выбрать().
и далее пока следующий().

(0) Если там не 100500 связанных объектов, то это кривой код у тебя. Через КД2 будет на порядок быстрее.

(8) выбрать и выгрузить разницы на x64 нет

(10) Нигде нет разницы.

На 32 выбрать делало через файл большие выборки

(9) там кода 5 строк..
проверка по артиклу если нет то создаем новую позицию и все..
я так понимаю что сама проверка по артиклу с каждым разом все дольше и дольше ибо номенклатуры все больше и больше. но без проверки будут дубли

(12) Любое обращение к результату запроса грузит в память всю выборку.

(13) если индекс есть, то разницы нет

(13) >создаем новую позицию

Скорее всего тут и тормозит

Надо начать с количества записей в транзакции.

(13) Запрос в цикле по каждому артикулу?

А что замер говорит, какая операция самая долгая?

(0) Наймите нормального грамотного программиста

ЗЫ Ты там не через COMОбъект случайно?

(13) Кто мешает сначала взять все артикулы, которые есть в загружаемой базе (их же немного) натравить на базу из которой загружаем и там пометить каким-либо образом те объекты, которые нужно выгрузить.
А потом забирать только их не проверяя каждый раз в приемнике.

(21) тормозит запись, а не поиск

(22) Да хрен его знает что там тормозит

Ну и желательно при записи всякие версионирования отключать, может даже и жр

Другой вопрос. а как можно узнать (не заходя в ЖР поиска там).
Когда создалась определенная номенклатура? или только по ЖР?

Запись и тормозит. Если версионирование включено, то и оно тоже.
В транзакциях нужно записывать. Порциями.

(25) Если есть версионирование, то лучше там

(26) транзакции кмк только на 77 ускоряли.
На 8 все равно транзакция сначала в журнал скл на диск пишется

ОбменДанными.Загрузка = Истина? мож там 100500 проверок еще при записи, вот и увеличивает время

Если записывать в транзации порциями и поставить обменданными.загрузка=истина
это на много ускорит ? если разница будет между 7.5 днями и 7 днями )) то смысла дергаться даже нет.

(27) версии по номенклатуре не ведутся

(30) + в несколько потоков запустить

(30) ОбменДанными.Загрузка может существенно ускорить при условии того, что будут отключены все проверки(например, на дубли), все подписки и прочее ненужное. если всего это нет - то не ускорит

(30) замер то когда запустишь?

(34) так что бы запустить замер нужно выключить загрузку ;) а то замер будет не правильный. загрузка то идет.

сейчас встал вопрос. как без версифицирования вот узнать когда номенклатура создана? искать по ЖР? хочу проверить кое что

(35) https://www.youtube.com/watch?v=vy-I7ybkH-c

(35) зачем?

(35) на копии никак? )))
в чём тогда вообще смысл вопроса, если загрузка идёт всё равно )))?

(35) если из конфигуратора запускал предприятие, то ничего перезапускать не нужно.
Да и вообще я бы уже давно остановил такую загрузку

(35) А какая тебе разница? Заново загрузится не может из-за проверки по артикулу. См. (0).
Боюсь спрость: не всё в одной транзакции?
5-7 позиций в секунду, ну... такое надо отменять сразу же, это ты где-то накосячил, так быть не должно!

(0) объединял два документооборота? цифры примерно похожие были, запускал в несколько потоков, причем чтобы отслеживать статус потоков для каждого потока в каждом потоке генерировал HTML страницу и записывал, при обновлении на клиенте этой сранице видел сколько загружено и сколько осталось;-)))

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

(43) + и запись в режиме обмена данными

(39) В том что это не разовая штука

А если через универсальный обмен загрузка XML ? базы то идентичные

(45) У тебя будет целовое время

через универсальный обмед xml быстрее не будет ? я могу кинуть во второй базе (все ном группы в папку "выгрузка").
создать в первой базе папка "выгрузка".
следовательно при загрузке он должен всю номенклатуру закинуть в папку выгрузка ну и далее по папкам.

(46) в любом случае нужно будет правило обмена писать. А там с номенклатурой много чего другого интересного тянуть надо. Это и картинки и упаковки, а для картинок еще и регистры сведений тянуть и т.д.

(49) там пустая номенклатура.
наименование, вид, ставка, ед измерения наименованиеПолное.

смысл что бы перенести ее всю, так как есть в правильные папки и подпапки и подпапки под папки.
картинки и т.д. это потом из другого места

(0) примитивный запрос на булке перенесёт секунд за 30, наверное

4.5 млн это ни о чем..даже примитивный insert into select справится за несколько минут

жахнуть через скл напрямую

(52) +1, булккопи тоже должен решать быстро

(11) недавно как раз столкнулся с https://its.1c.ru/db/v8std/content/725/hdoc
через объектную модель не грузит

Вариант грузить только те позиции, что есть на остатке, либо только те, по которым было движение в течении года-двух, поставив предварительно галку какую то. Запихать в табличный документ со всеми реквизитами, а дальше на 10 потоков распараллелить чтение и запись.

(56) Я фигею с 1с очередной раз ...

Неправильно:

Также неправильно:

Запрос = Новый Запрос;
Запрос.Текст =
  "ВЫБРАТЬ
  | Номенклатура.Ссылка,
  | Номенклатура.Наименование,
  | Номенклатура.ВидНоменклатуры
  |ИЗ
  | Справочник.Номенклатура КАК Номенклатура";

РезультатЗапроса = Запрос.Выполнить();
// Обход результата запроса
ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();
Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
  // Обработка элемента выборки
  // ...
КонецЦикла;

Нафига тогда вообще запросы нужны

(58) не каждый запрос правильный.
само наличие запроса не панацея

(58) дальше почитай, правильно "Выбрать первые 1000"

(0) Мне кажется странной такая задача. Может дело не в скорости выгрузки, а в постановке задачи?

помнится приходилось с таким сталкиваться, но решение приняли такое - есть обмен, которым в дальнейшем будем пользоваться , он отлажен
нового ничего не изобретаем , грузим пачками в несколько потоков
закончится через неделю - ничего, зато не будем огребать каких либо ошибок

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

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

(64) Ну 7 элементов справочника в секунду это долго

(65) но еще и скрыто на какой типовой все эти кувырки происходят.
Может там и не типовая уже давным-давно, а потому нужно отрубить кучу всякого ненужного, что происходит в обработчиках и подписках вокруг записи элемента

кроме вышепредложенных, запись по 1000 новых элементов в транзакции и монопольно поможет ускорить выполнение

при желании, можно прямо в коде замеры времени получать и регулировать количество элементов в транзакции в большую сторону, пока оценка не начнет ухудшаться
ЗамерВремени/Количество можно сравнивать с предыдущим. Начальное значение большое, а дальше вычислять.

(67) а оно реально работает? кто-нибудь делал тесты?

(69) работает

(0) грузи сразу в скуль

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

(70) что-то я тестов никак не могу найти. Интересно делал ли кто-нибудь?

(73) и на 1с нет такой рекомендации для 8.

(73) да

(75) и что какие результаты. во сколько раз ускорение?

(76) запрещено к публичному разглашению

(0) Поле артикул проиндексировано ?
Через что грузишь ? помоему через конвертацию такое точно в разы быстрее должно делаться как минимум

(0) что тебе мешает на уровне SQL перенести таблицу?

1. Запись в транзакции порциями по N элементов
2. Фоновые в несколько потоков
3. Сначала во внешнюю базу выкинуть оба справочника и там сравнить запросом оставив только те что надо записывать. Результат в CSV и читать из него по N.

(80)+ 4. ОбменДанными.Загрузка = Истина при необходимости

Попробовал через УниверсальнуюЗагрузкуВыгрузку xml с отбрром по группе (выбрал 1 группу для теста).
Но не понятно там есть функция FastInfoSet . типо быстрее работает.
Выгрузка через xml выгрузилось и загрузилось норм... выгрузка шла секунд 20. одной группы.
Далее попробовал с галочкой фатсинфосет. выгрузилось секунд за 10.. то есть результат на лицо... А при попытки загрузки тут же выкинуло с ошибкой чтение xml и далее куча кода... при условии что быза типовые и обработка типовая и все типовое.

Еще более быстрые варианты это писать напрямую в sql базу что сложно.
Если база небольшая то выгрузка в DT (или "Выгрузить данные для перехода в сервис") добавить строчки и загрузить назад.

(82) гыгыгыгы

(83) ну как не большая.. в базе 4.5 миллиона номенклатуры (без учета остальных документов, приходов, реализаций, и т.д.). как думаешь не большая ?
зачем фирме 4.5 миллиона позиций. если у них 1 реализация в год))))

(80) п.3 это например https://habr.com/ru/post/547448/
или ms access если к mssql нет доступа и умений

(85) Автозапчасти там номенклатуры может быть еще больше а реализаций не много
DT сколько гигов?

(85) ну может у вас военка какая-нибудь и вы ведете учет НЗ на складах? Там вам несколькими доками наполнили склады и все, лет на 30 закрыли на клюшку)

(87) я ни разу не пробовал выгружать базу в ДТ, в sql 180 гигов весит. сколько в ДТ беспонятия

(89) примерно столько же, сколько бекап скуля сжатый в архиве.

(82) гыгыгыгы x2

(0) >>В среднем за 1 секунду, вижу что создается 5-7 новых позиций

Как-то чрезвычайно медленно. Стрельни замером. Может там тупые проверки в каких-нибудь подписках на события сидят. Или какая-нибудь тупая регистрация на обмен

(89) это маленькая база

(0) "4.500.000" - зачем столько?

(92) скорее тупой поиск по артикулу

(95) поиск по индексу артикула по сравнению с записью объектов - на порядки быстрее должен быть...

(96) Если он идёт непосредственно в базе по каждому артикулу, то не на порядки.

(85) Ну про автозапчасти пример правильный, там действительно 1 реализация может быть. ) Маня не даст соврать. Кстати, он на этих загрузках номенклатуры собаку съел.

(85) ценообразование сделать и на сайт отправить

(82) Попробуй теперь через ЗагрузкаДанныхИзТабличногоДокумента, с поиском.

(0) Ты сейчас пытаешься "сделать что-нибудь и как-нибудь" вместо обдумывания самой задачи в комплексе. Для чего эти переносы вообще? Исходи из постановки задачи.

(101) Уже начал бы перегрузку, пока думает как решать задачу ;-)

(0) Запросом выбери всю Номенклатуру -> Артикула, которые есть у тебя в базе, положи это в Структуру.
Далее, перебирая свой файл смотри, есть ли твой элемент в этой Структуре. Это намного быстрее кучи запросов к базе. Вместо СТруктуры можно воспользоваться Таблицей значений и создать на ней Индекс по полю "Артикул".
Создание элементов оберни в цикл, типа так:
НачатьТранзакцию()
Счетчик = 0;
Цикл
Счетчик = Счетчик + 1;
Если Счетчик%50000 = 0 Тогда <- тут можно поиграться с размером
ЗафиксироватьТранзакцию()
НачатьТранзакцию()
КонецЕсли
КонецЦикла
ЗафиксироватьТранзакцию()