Всем доброго времени суток.
Есть независимый непериодический регистр сведений. Измерения-поставщик, номенклутура, характеристика(характеристика строка) и измерение цена.
Читаю прайс-лист в миллион строк (плюс-минус  200 тысяч). Пишу это добров в регситр.
Сабж. Метод СоздатьНаборЗаписей()...Добавить()...Записать() не канает, так как встречаются одинаковые характеристики, из которых велено брать первую. Поэтому каждый раз делаю СоздатьМенеджер()...Записать(). Даже в рамках транзакции 400 тысяч почти три часа. Эска (файловый вариант) ест гиг оперативы. Пробовал транзакциями по 10 000 записей - прироста скорости замечено не было.
Как можно оптимизировать?

(65) будем пробовать.

(67)Оракл вообще отдельно хранит твои наборы данных и делай ты с ним што хошь:-)  Но мы же про скуль говорим.

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

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

Недавно организовал "онлайновую" (опрос с интервалом 60 сек) синхронизацию номенклатуры 1С с базой SQL (из SQL в 1С). Размер номенклатуры полмиллиона. Первичная загрузка при подключении чистой базы 1С занимает около 2-х часов. Дубли проверяются (у меня это не дубли, а обновление, а отличии от добавления). Около 90% времени занимает запись в базу. Загрузка идет пакетами по 500-1000 записей. Для выборки на изменение пакет размером 1000 записей грузится во временную таблицу, затем выполняется запрос. Такая проверка на дубли занимает 1% от всего времени.

У тебя регистр, а не справочник, поэтому можно попробовать грузить пакеты, а не по одной записи, как у меня.

+(71) Все тесты делались на моем ноутбуке, для хорошего сервера будет быстрее.

(71) у вас тоже из SQL была промежуточная выгрузка в файл? Нет?
Тогда почему вы утверждатете, что это одно и тоже при том, что чтение из txt занимает у 1с чудовищно много времени?
это окромя обработки такого количества, о чем мы выше спорим )

(73) чтение из txt было построчно или сразу весь прочитали?

(69) именно, что в реляционных СУБД хранятся избыточные данные (создается, к примеру, вместо одной таблицы - три, где связи между данными и назначение таблиц определяется ключами-идентификаторами), но это позволяет мгновенно находить нужное.
1с же "откапывает" из-под слоев ссылок то же самое, тратя время на обработку раскопок. Это занимает меньше места в базе (ссылки же везде), но удлиняет и усложняет обработку - кроме непосредственного распутывания клубка еще надо и проверять корректность типов извлекаемых данных, всякие там проверки делать...
(74) если вы подразумеваетет под "сразу весь прочитали" Файл.Открыть - то открывается сразу и весь.
А читается все равно посторочно, а как иначе? Вы как полученные строки обрабатываете - 1с сама распределяет данные, куда заблагорассудится? )))

+ вернее, там Файл.Прочитать... но не суть важно...

(73) Нет, чтение было сразу из SQL, но через VPN, прокинутый по интернету :)
Я не утверждаю, что это одно и то же.
Но если честно, сомневаюсь, что такая простая операция, как чтение из TXT (с локального диска!) может заметно тормозить все дело. Если тормозит - это повод для анализа. Может, он читается построчно или целиком, но не помещается в память или что-то в этом роде? Может, стоит его читать через ADO?

(73) Какой объект использовался - ТекстовыйДокумент? Что конкретно тормозит - ПолучитьСтроку?

(71) по отладчику запись занимает 60% времени.
(73) файл читал способом ПрочитатьСтроку(). Текстовик весит 20 метров. Читать целиком побоялся.
(77) Памяти 3гига, из них винда и прочие отъедают меньше одного. Основная проблема видится именно в записи.

(77) это как через ADO? текстовый файл он не предоставляет механизма доступа к самому к себе ))
Тормозит стандартная 1с-я команда Прочитать-Текстовый-Файл (давайте не будем гонять меня в конфигуратор и искать, как она там выглядит :)

(80) у кого тормозит команда ПрочитатьФайл?

(78) ну конечно тормозит не открытие файла, а построчное чтение. И строки вы как еще получатете из текстового файла?

Если написать ОбменДанными.Загрузка=истина и отключить использование итогов то в 1с запишется быстрее. )
(82) ну вот. )

(83) а как иначе? ))
какой ОбменДанными с текстовым файлом, простите? ))

(84) причем тут текстовый файл уже, я про запись в 1с. )

(83) у меня регистр сведений - итогов нет. В каком месте надо писать по Вашему ОбменДанными.Загрузка?

(79) - 60%? Это через менеджер записи? А через набор - быстрее? (Хотя бы просто попробовать, пусть с дублями для начала). Дубли отсечь - просто, уже написал как.
(80), (82)
Текстовый файл с разделителями можно открывать через микрософтовские источники данных как таблицу. Сам не пробовал, это просто как идея, может это будет хуже.
То есть, у тебя чтение из текста занимает больше времени, чем запись в 1С?
 Если честно, последовательное чтение текста - очень простая операция, ну не должна она тормозить.

(0)-(83)
А что такое миллион строк в прайсе?  Вы представляете себе ассортимент товара такой компании? Там менеджеры продаж повесятся или сбегут.
Даже в современном самолете боинге "дрим лайнере", всего 90 тысяч полуфабрикатов и материалов по 2 тысячам поставщиков.

Автор у вас там что? Весь РосАТОМ или весь РосКОСМОС.
Зачем придумывать задачи которые никому не нужны!!!
Если вам нужен анализ, то поставьте себя на место пользователя, для которого вы ВЫДУМАЛИ и РЕАЛИЗОВАЛИ возможность анализа цен по миллиону записей и десятку аналитик.

(85) в (9) из текстового файла грузится

а про запись в базу - это с (71) поста началось, мы более общие вопросы обсуждали ))

(87) ексель откроет и правильно распределит 20мб текста? сомнительно....

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

(87) >>  Если честно, последовательное чтение текста - очень простая операция, ну не должна она тормозить
а в 1с пошли своим путем ))

(71) +1

(92) наверное, ВЫГРУЖАТЬ нужно будет только изменившиеся позиции ))

(88) Ассортимент не представляю, он передо мной, более полмиллиона :)
Это справочник номенклатуры моего клиента. Чем занимается клиент говорить не буду, но ты задумывался, сколько номенклатурных позиций, например в справочнике яндекс-маркета? :)

(94) я не понял шифровку - +1 как относится к оптимизации? ))

(88) количество деталей, производимых концерном VAG составляет более 6 миллионов позиций. Из них в РФ поставляют чуть меньше трёх. С учетом характеристик ЛКМ получается очень весомо. Попрошу не оффтопить и не хамить.

(95) +1

А вообще вопрос о том, как оптимизировать загрузку большого количества значений в регистр сведений. Вернее как оптимизировать запись всего этого в БД.

(97) да какая разница, прайс это или не прайс.
Если клиент БУДЕТ оперировать такими данными, готовьтесь к текучке 1с-админов-программистов.
Ибо еще НИКТО не заставил 1с обрабатывать огромные объемы и не подавиться ))

100

(98) >> как оптимизировать загрузку большого количества значений
если отсечь чисто организационные (порции, нерабочее время), то только выбросить промежуточную выгрузку и заставить базу-источник предоставить ADO-COM.
Больше вариантов не вижу.

Таки никто? А если писать напрямую, а не через механизмы 1с?

(98) Хранить отдельной таблицей в скуле. Запись в 1с никак не оптимизируешь. Еще раз говорю - 6 миллионов - это постоянные детали с постоянными характеристиками. Их нужно записать только один раз.

(102) напрямую куда? а 1С их как читать будет?
(103) а 1с как их пользовать будет?

(104) Напрямую в скл. Или ты думещь, что 1с делает это иначе?

(104) Например во вспомогательную скульную базу. 1с без проблем с этим работает.

(105) да уж, 1с-программситы такие затейники, из любой базы в SQL кинут ))
>> что 1с делает это иначе
именно что 1с делает (точнее, 3х уровневая система), а не пользователь напрямую ))
(106) опять же: обработка?
и как 1с будет номенклатуру брать - в SQL ссылки давать? ))

(107) то есть ты не умеешь напрямую создавать 1с-объекты в скуле. Так и запишем.

(108) ага, т.е. вы напрямую получаете ссылку на Номенклатуру и саму номенклатуру? Минуя 1с-сервер? так и запишем.

(109) Заканчивай ламерить... Ты уже поддостал...
Кто мешает создать запись в скуль-таблице и получить её ид? Я подскажу, что...

(101)
Так я подсказал же вариант - писать через набор записей пакетами на добавление, дубли отсекать до записи. Что бы выяснить целесообразность такого пути, нужно попробовать, насколько быстрее запись пакетами на добавление. Это делов на 20 минут. Если выяснится, что это, скажем, в 5 раз быстрее, то примерно во столько же раз можно ускорить эту байду. Без всяких прямых доступов к базе и прочее.

вносить прямо в скуль уже предлагали? 1с и по быстрому - вещи не совместимые

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

(112) мечтатели вы, господа ))
1с свой сервер придумывала для прямого чтения/записи в SQL без его участия? ))

(102) Ты что, это же нелицензионно! :D

(114) гы... ты думаешь сервер приложений делает с данными нечто высокоинтелектуальное?

(115) наличие этой строчки в лицухе 1с всегда потешало

записывай в наборе по 1000 записей, перед добавлением проверяй на дубли

(115) Если это отдельная база данных в скуле - это что в этом нелицензионного? Рарус во всю юзает для обмена.

(118)+ перед добавлением отключи индексы для этого регистра сведений, потом обратно включишь и переиндексируешь

+ (118) Делал в наборе по 10 000 записей, всего по подсчетам получалось около 5 000 000 записей, и ничего. тога прочитать потом сложновато.

(118)+ перед добавлением в наборзаписей проверять на дубли, а не в регистре

(119) Речь не про отдельную базу.

(111) Еще в порядке бреда. Добавить в регистр измерение а ля счетчик, писать с дублями, резать дубли после загрузки.

(119) >> Рарус во всю юзает для обмена.
именно для обмена. Т.е. данные все-таки загружаются позже в 1с-базу.
(116) я думаю, что сервер записывает данные в такой структуре, которая читается средствами 1с потом, а не прямым обращением к SQL из конфигуратора.

(0) откажитесь от регистра сведений, сделайте справочник без кода и наименования

ну если непременно хочется регистр сведений - избавьтесь от измерений. Сделайте измерение - счётчик

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

(113) я где-то сказал про ид строки? Где????

(124) Соответствие ГУИД-ов двух баз (с наименованиями) хранится в третьей и редактируется через обработку. В обработке доступны все команды обычного SQL update,delete,insert. Ну так пиши свою обработку и храни хоть сто миллионов записей. А уж что ты сними делать будешь - дело твое.

(124) А что мешает писать напрямую именно в такой структуре?

+(130) Ну, кроме ЛС, конечно ;-)

(4) Насмешил. Особенно если учесть что есть биллинг на 1с.

(130) что писать - типовую? ))
(129) а что мешает тогда продвинуть идею подключаться сразу к базе источнику и оттуда брать все данные?
>> Соответствие ГУИД-ов двух баз (с наименованиями)
на одном конце - миллион записей, на другом (1С) - нет ничего (ничего ведь не перегружаем). Соответствие между чем и чем будет?

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

(134) Не говори сказки . Как можно обрезать если глубина перерасчета 3 года в коммуналке?

(135) Мало того что знаю как работает , так один в общем написан. Который сейчас работает на миллионе абонентов.

(136) тогда к (32)

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

(133).1 Ээээ ... при чем тут типовая? Ты за нитью разговора вообще следишь? Еще раз, что мешает писать данные напрямую в sql-ную базу в том самом формате, в котором их пишет 1С?

(138) Вы всё делаете не так. Вам же сказали, 1С не предназначена для нормальной работы. Если ваша программа написана на 1С, то она не может работать, не может, не может, не может.

(138) опять ВТ...
у вас либо данных мало, либо суперкомпьютер стоит, а не сервер.
Я спецом проверял на десятках тысяч записей свои запросы: делал идентичные, разница - одни на ВТ, другие суммированием (ес-но, где можно было сунуть ВТ, т.к. и это очень и очень ограничено к применению); в 40% разницы между ВТ и обычным обращением нет (составляло доли секунды по замерам).
Не говоря уже про примеры выше.
У 1с тоже в презентациях все прекрасно.
Но что-то с внедрениями капец полный. Или никто виртуальныные таблицы не использует? принципиально?

+ да, где ВТ давало наибольшей эффект, было не мгновенно, а всего раза в полтора быстрей - вполне соизмеримо.

(141) Ладно ,верю верю .

(46) > Мильен записей  записать- это и в Африке мильен записей
Немного оффтоп: на Оракле (да,да,на "дорогом атомобиле") каждую ночь обрабатывается ~90млн.записей, происходит их АГРЕГАЦИЯ, запись/обновление ~15млн.записей.
Самая большая таблица приближается к 3,5млрд. записей (растет на 7.5млн/ночь).
Это дело занимает ~4-8часов времени

(144) + аВтомобиле *

(144) 7.5 млн за ночь , какой же этот Оракл тормозной )))))

(146) если есть предложения ускорения, РАБОТАЮЩИЕ предложения, буду только за )))

(147) Я не буду делать рекомендаций и выводом без обследования системы.

(0) ускоряется элементарно, весь регистр сведений читается в тз, в тз добавляется строки из загружаемого файла,тз сворачивается по измерениям и записывается в регистр. тысяч 120 строк проводок бухгалтерского регистра на нормальном сервере записываются за 15 минут, с регистром сведений всё будет намного быстрее. Мишу Лажаагра можешь не слушать, он года два сопли размазывает по форуму, никак 8 не выучит.

(149) Если делать на сервере , то взлететь может . А на толстом клиенте можем упереться в 2 гига.

(144) я базульку 30гигов копирую за 40 минут на скуле, без аггрегаций, но с отбором. это порядка 30млн записей во всякие физические таблицы...
чтото гдето не так ИМХО..

(151) т.е. простой insert .. select .. where .. ?

без маппингов, staging area и т.д.. ?

(151) т.е. у тебя "репликация" / разовая операция / ETL ?

(151) копируешь каким методом?
в журнал транзакций что-то пишется?

(149) Спасибо, примерно так и сделал - скорость записи увеличилась ровно на порядок.

(149) ага, так ну их эти регистры вообще - давайте все в ТЗ и в память??
1.2 млн записей : 120 = 10
15мин х 10 = 150 мин, реально 3 часа.
Да, теперь клево, за смену управимся. Главное, не давать базе распухать.
Это если еще хватит памяти под передачу 120 тыс строк на "нормальном сервере".
А что уж не лабораторные исследования 1с - у них вообще за 20 минут все гоняется-обрабатывается.
Только чаю попить.

Всем привет.

Опять баяны трете? А в поиск ходили?

(158) Привет.
Так кто же их пошлёт...

ну не читают "старожилы" баяны ))
или забыли уже ))

(155) копирую из одной базы в другую средствами скуля без нихто и то с включенными индексами.
правда диск "быстрый" =) но на базу в несколько лярдов записей медленные диски - это извините извращение

(161) ничего, что у вас SQL напрямую сам с собой работает, да еще и системы хранеия (да и сервера наверняка) оптимизированы? ))

(162) для тех кто в танке мы обсуждаем оракл и 15млн записей за 8 часов.

На Инфостарте О-Планет как-то писал статью, как он в файловой 1С 7.7 автоматизировал лотерею. Если это не фарс, а задача, смотрю, сходная, можно поискать оное.

(163) для тех, кто под танком: кто будет писать взаимодействие между оракл и SQL??
и еще, кто совсем под танком: в основном обсуждается запись в 1С-БАЗУ.

(165) дааа.. танк совсем непробивной =) общались не с тобой про оракл/скуль (не взаимодействие, а производительность этих СУБД), ты влез.. тебе оно надо?

Успокойтеся, у нас не просто запись в таблицы Оракл/МС-СКЛ, как у Акселя.
У нас ETL, что подразумевает и staging и маппинги и проверки и агрегацию (суммы, нумерация, и т.д.) и конечно же индексы и констрейнты на хранилище.
Также переливка данных идет не локально на сервере, а через дблинк с другого серва.