1с8.3.9
Надо заполнить оборотный регистр данными.
Неожиданно столкнулся с ограничением на размер табличной части документа в 99 999 строк.
Можно ли это обойти.
И как заполнить регистр большим объемом данных, используя 1с Предприятие 8?

(132) Ясно, что отчеты НЕ будут содержать много строк. там будут соответствующие отборы и группировки.

Хотя вот в УТ11 есть типовой Ввод остатков и там есть загрузка продаж - табличные части Оптовые продажи и Розничные продажи.

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

По факту для Exell 500 тыс.строк имеем
1. Чтение файла 40 сек
2. Сопоставление/Создание справочников 5 мин
3. Проведение 2 мин.
  Это без оптимизации по скорости. С учетом того, что это делается 1 раз в месяц, то можно и не оптимизировать. Оптимизация скорости даст ускорение 3-4 раза.

(143) Конечно это не типовая конфигурация. И тормозов там нет на уровне 20-50 тысяч документов в день

Ну если так) то Успехов) Смысла чего то тут дальше обсуждать нет

Интересные идеи были высказаны. Осталось только реализовать и посмотреть быстродействие отчетов на СКД для большого объема данных

(147) то есть разрезу в которых крутить данные будут - уже известны?

Разрезы известны.
    ТорговаяСеть, ФрматТорговойСети, Поставщик, ГруппаТоваров, ПодгруппаТоваров, Товар
    Себестоимость, Количество, Стоимость
    Периодичность

(149) Вот просится тут BI, просится :))

(150) ну так я два раза товарищу сказал. он видимо непривычные слова услышал и пропустил мимо ушей.

Короче медленно но верно работа идет.
Реализовал табличную часть через регистр Сведений.
Документ с количеством строк в табличной части = 700 тыс. строк  работает довольно шустро.
       Для 700 тыс строк. Размер Exell файла 20 Мб, Количество ячеек порядка 10 млн.
1. Импорт данных с предварительной обработкой - несколько минут
2. Сохранение документа 10 сек
3. Проведение документа по оборотному регистру 10 сек

   1С жива на данных объемах, а вот Exell при импорте умирает на уровне 500 тыс строк. Приходится читать частями

Ожидаемое количество строк оборотного регистра за три года работы федеральных сетей - 300 млн. записей
Здесь и встает вопрос чем этот регистр Анализировать.
Что-то внутреннее чувство мне говорит, что СКД здесь не справится

(152) кстати, а как быстро 1С читает эксель через табличный документ не проверял на таких объемах?

Для 700 тыс строк.
  Если читать через
        // Массив типа COMSafeArray
        Массив = Лист.Range( Лист.Cells(НачСтрока, 1), Лист.Cells(КонСтрока, КолвоКолонок) ).Value;
  тогда несколько минут
  если построчно, то раз в 10 медленнее
  если через АДО, то раза в два быстрее

(155) а средствами 1С через
ТабДок.Прочитать(имяФайлаЭксель);
?

COMSafeArray умирает при количестве 500 тыс. строк и количестве колонок 25
Приходится читать частями

(156) А так я даже на пробовал. А так можно для .xlxs  ?

(153) Как раз для оборотных регистров в 1С были придуманы агрегаты.
Насколько вам подойдёт этот механизм - зависит от того что конкретно вы там собралисб анализировать.

Простейший оборотный регистр.
  Измерения:
     ТорговаяСеть, Клиент, МагазинТорговойСети, Производитель, ВидПродукции ТипПродукции, НаименованиеТовара
  Ресурсы
     Себестоимость, Количество, Сумма

(158) давно уже. Интересно насколько это быстро работает на больших объемах

Ограничение на 99k строк то не случайны.
При открытии документа они все читаются в память сервера 1С.

(152) динамический список с отбором?

(161) Посмотрел я ТабДок.Прочитать(имяФайлаЭксель)
Все не так просто. Там оказалось, что файла формата *.xlxb
Такой формат 1с еще читать не научилось

(163) Все не так просто. УФ на подобных документах умирает. У меня была попытка на УФ создать документ 30 тыс. строк. Там было очень печально.
  Здесь толстый клиент. Вопросов по созданию и работы с документом на 700 тыс. строк нет. Вполне комфортно

(165) "УФ на подобных документах умирает."

Вы просто не умеете их готовить.

(163) Отборы в табличной части документа на 700 тыс. строк работают великолепно. Никаких задержек. Для толстого клиента разницы между 700 строк и 700 тыс строк не замечено

(166) Не надо.
   Ваш рецепт работы с большими документами на УФ мне известен: "Разделите документ в 40 тыс строк на тысячу документов в 40 строк"

(168) Это не мой рецепт.

Когда я на УФ делал документ в 40 тыс строк. Это был чистый документ без всяких обработок. Открывался с трудом. А при попытке начать редактировать любую строку табличной части задумывался на несколько секунд. После этого опыта мы отказались от использования УФ в своей учетной системе, так как не было видно ни единой возможности победить большие документы.

(170) Вы просто охерительные ребята.

(170) Это эпик

Вот такие "спецы" уводят ИС организации, которая им ничего плохого не сделала в трэшанину вольных вызовов сервера с Толстого клиента и обычных форм.
Конфа хоть самописка?

(173) Значит вы подтверждаете свои рекомендации по поводу разбиения документа на части. По моему это были вы в нашем споре по возможности работы в УТ11 при большом количестве номенклатуры

рак - лебедь - щука

(174) Да если тормозило редактирование ТЧ (в чем я сомневаюсь, тормозит редактировать ТЗ, но не ТЧ) - всегда можно запилить РС и динамический список, но никак не пускать конфу на кривую дорожку ухода от всей типовой ветки развития.

Как там дела с маркировками? Вас пока не коснулось?

(176) Тормозило как раз редактирование ТЧ. И тормозило даже без перехода не сервер. А с переходом просто умирало.
Маркировка не коснулась. Но если доживем до маркировки, то это не будет типовая конфигурация. На типовых конфигурациях работать могут только ларьки

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

Но можно другим способом решить: Core i7 поставить на сервак, и обязательно сам сервер и всю серверную освятить.

(178) Про агрегаты я не понял. Слово красивое Агрегаты

(178) На УФ есть корректировка регистров? Что то я очень сильно сомневаюсь.

(180) В смысле? В большинстве типовых есть

(179) https://its.1c.ru/db/pubessence#content:144:hdoc
но не факт, что в данном примере это вот прямо обязательно нужно использовать.

(180) Рукалицо. Конечно есть.

Посмотрел я эти Агрегаты. Как и все новые фишки, эта фишка сделана через зад. Мне очень понравилось
"Если в информационную базу постоянно вводится много новых данных, перестроение нужно выполнять регулярно. Например, раз в сутки".
Как я понял, эти агрегаты имеют смысл только для периодичности, отличной от стандартной для регистра оборотов. В моем случае этой необходимости нет.

(0) На кой? Не надо в ТЧ хранить - просто воспользоваться документом Корректировка регистров. Последний во всех типовых присутствует.

(183) эта "новая фишка" присутсвует в платформе с версии 8.2, т. е. лет десять уже.

Грузить сразу в оборотный РН. Это если нужны сводные итоги. А то и в РС независимый можно. Непонятно, что тут обсуждать на 200 постов.

(186) Там же надо обработать первичные данные, привязать К контрагнетам, магазинам, возможно исправить ошибки. Поэтому табличная часть достаточно удобная. Видно, что проблем с такими большими документами нет.
  Сейчас остался вопрос с возможностью СКД работать с большим оборотным регистром.
  В четверг узнаем. Для начала на 100 млн. записях

Проблема управляемых форм-хождение на сервер без лишнего повода.

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

я думаю, что автору надо переходить на фузину!

Фузина, как сообщали разработчики, с этим справиться не может. Вернее может, если к ней прикрутить внешнюю BI базу для хоанения данных и внешнюю приблуду для построения отчетов.

1С с подобной задачей справилась со скрипом. Напомню постановку задачи. Имеются данные по продажам Федеральных Торговых Сетей типа Перекресток, Пятерочка, Карусель, Ашан, Дикси в виде файлов Exell. Общий количество строк в районе 100 млн. Надо все это затащить в оборотный регистр и сделать Анализ с помощью отчета на СКД.

(192) очень типичная задача, ага. Каждый одинесник рано или поздно с ней сталкивается

Сначала нарвался на ограничение в 99 9999 строк для табличной части документов. Разарботчики 1С почему-то посчитали, что для ларьков больше и не надо. В форме документа платформа дает возможность заполнить документ как минимум в несколько млн строк, но при сохранении говорит, что сохранить может только 99 999. Пришлось делать РегистСведений для хранения табличной части документа. При открытии табличная часть восстанавливается из регистра сведений. При проведении данные берутся из этого регистра.
  При таком подходе можно вполне комфортно работать с документами по 200-300 тыс строк, и чуть менее комфортно с документами по 1 млн строк.
  Типичные параметры при работе с документами в 1 млн. строк:
1. Время открытия - 30 сек
2. Время сохранения - 2-4 мин
3. Время проведения по одному регистру 4-5 мин

Вторая проблема была чтение документов EXELL размеров в 1 млн строк. Построчно читать такие файлы не реально, поэтому такие файлы читаются кусками по областям исходного документа. Здесь возникло ограничение 100 тыс строк. Если больше, то Exell не мог прочитать такие области. Но частями по 100 тыс строк читал без проблем. Типичныое время чтения файла размером 1 млн строк:
1. Примерно 1 мин

Програмное заполнение табличной части в 1млн строк. Здесь проблем не возникло. Типичное время 2-4 мин
Обработка табличной части. Все великолепно. Отборы, установка реквизитов. Время в районе 30 сек.

(194) (195)
1. Для чего человеку оперировать документом в миллионы строк? тут не в ларьках дело
2. Это проблема не 1С, ексель сам не может работать с такими объёмами
Такое ощущение, что вы пытаетесь в гараже адронный коллайдер запустить

Проведение. По одному оборотному регистру 1 млн строк - 4-5 мин.

(197) Нормально работает EXELL c документам 1 млн строк. Время открытия  в районе 10 сек, а всякие отборы на лету.

(198) зачем

Эта задача не есть какое то новое слово в 1С. Просто интересно посмотреть как ведет себя 1С на больших объемах информации.
Зачем такие документы? Задача такая.

(198) пиши сразу в регистр, зачем проведение?

(201) а почему делали табличные части, а не сразу вывели движения документа для редактирования, по нужному регистру? Думаю время бы сэкономили.

(194) а зачем два лишних действия? имитация табличной части, проведение по регистру? чего сразу не грузануть в движения?

(203) если вывести 1кк строк движений для редактирования то клиент умрет

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

в твоем случае лучше эмулировать ТЧ через рег сведений

В данном случае работа в тонком клиенте даже не рассматривалась. Тонкий клиент умирает уже на уровне 50 тыс строк. В толстом все более менее нормально. Просмотр движений дркумента на 1 млн. вполне работает.

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

Короче за достаточно короткое время удалось залить в базу 100 млн строк. И посмотреть как работает СКД с такими объемами информации. Изначально я как то скептически был настроен по поводу СКД. Здесь 1С меня приятно удивила. СКД вполне работоспособен. Видно было, что SQL уже подтормаживал. Если сделать отчет по всем записям, с разбивкой по периодам, то при первом запуске отчет выполняется где-то секунд 30-60. После этого SQL таблицу в кеш, и после этого время выполнения в любых разрезах - несколько сек.

(209) Да. Это вполне реально. Типа привязать к нужному контргенту, номенклатуре, проверить корректность заполнения. Отбор, групповая обработка строк. Я так обработал 100 млн. строк :)

Что порадовало в 1С при обработке больших объемов данных
1. Работа кэша. 1С научились немного работать с кэшем. Было видно, что кеш корректно выделялся и чистился как на клиенте так и на сервере
2. 1С может работать с такими объемами данных
3. СКД можно использовать для отчетов по большому количеству данных

(212) скд на вывод 100 млн строк или для обработки?
если для обработки - это все сиквел, а для него 100кк не особо много

(212) версия платформы?

Что огорчило в 1С
1. Отвратительное использование памяти.
Исходный файл EXELL в 1 млн строк занимает 30 мб. При прочтении этого файла в таблицу значений 1С требуется уже 8 ГБ оперативной памяти. Exell открывает это файл за 10 сек, 1с открывает документ с этими данными в районе 1 мин.
Exell требуется 150 мБ для работы с этим файлом 1с - 8 Гб
2. Глубокая однопоточность 1С. В моем случае было жестко видно, что 1С работает строго в один поток. Даже если использует несколько ядер. У меня 4 ядра, и видно было стандартная суммарная загрузка 25% при этом загрузка плавно перемещалась с одного ядра на другое.
3. Плохое использование диск. 1С насилует диски по черному

Платформа 8.3.9.2233 толстый клиент. Конфигурация десяток справочников. Один документ. Один регистр сведений с табличной частью. Один оборотный регистр. Один СКД отчет. НИкаких БСП. Размер конфигурации нескоько мБ

Размер базы данных SQL - 120 гБ. Размер выгрузки базы 10 гБ. Самое интересное что размер этих же данных в Exell - 4 Гб в формате .xlsb

(215) ну многопоточность нужно ручками писать вообщето

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

Напоследок:
У меня получилось в районе 120 документов на 100 млн строк. Групповая обработка и проведение  всех этих документов занимает в районе 1 суток. В один поток, в несколько потоков не получается, так как нарывается на блокировки. Для проведения и обработки требуется минимум 8 Гб оперативки как на клиенте так и на сервере. Ну и с большой долей вероятности эта обработка завалит сервер 1С  :)

(219) Фузина сказала, что им такое не под силу без привлечения сторонних разработок. Здесь же все штатными средствами 1С

(221) Ты сидишь и плачешься на штатные средства 1с, не сделав ни единого шага, чтобы это исправить. И кто тебе после этого доктор?

(222) А зачем мне это исправлять? Здесь нет задачи активно работать с этими данными. Задача сделать десяток раз отчеты маркетологом. Раз в месяц за 30 мин добавить месячные продажи всех федеральных сетей. И забыть об этом. А вот увидеть границы использования 1С данная задача вполне позволяет

(223) Границы твоего ограниченного разума, а не применения 1с.

(222) да вроде не плачется он, а рассказывает как и что работает

(221) А как же заявление фузиновцев о мильонах строк в документах? и трех строк кода?

(226) ну это они могут, а вот отчеты не умеют, только би покупать

Фузиновцы сказали, что они могут обработать мрд. строк, но с помощью DRUID. При этом этот млрд. это не наш 1 млрд, а 1 млрд строк с учетом итоговых записей по измерениям регистра.  Т.е их млрд - это наши 100 млн

Интересно было бы посмотреть размеры таблиц 1С по моим 100 млн. записей, но не работает SQL menegment Studio

Ограничения по многопользовательской работе в 1С можно оценить как 1 млн движений по всем регистрам в сутки. Или где-то 100 000 строк документов в сутки. Или 10-20 тыс документов в сутки. Это соответствует небольшой сетки магазинов или одного магазина на 100 касс.

Меня расстраивает следующее: реальная ситуация - у клиента под 1 млн операций в день. Каждая операция - это приход/расход денег и расход/приход товара.
И получается 2 крайности и один промежуточный вариант:
1. Документ с 1 млн строк, который будет делать проводки по регистрам денег и товаров. Но есть ограничение на количество строк в табличной части, а значит приходится делать регистр сведений, который подчинен регистратору и хранит информацию об операциях, но делает записи по регистрам более-менее быстро (ибо сразу есть вся выборка).
2. 1 млн документов с одной операцией, которые проводить приходится по одному (т.к. 1с не умеет писать наборы регистров накоплений по разным регистраторам), а значит даже при параллельном проведении возможны блокировки. Я уж молчу про регистрацию в плане обмена.
3. Промежуточный вариант - дробить документы по 5/50/100 тысяч строк. Но когда вдруг надо исправить 1 операцию - ты сначала найди ее в этих документах.
И шо тут сделаешь?

(224) всё по делу, конкретно с цифрами, интересно.

(231) Из за этого и пришлось городить документ в 1 млн. строк. Одно дело 200 документов в 1 млн строк, другое - 20 000 документов по 10 000 строк.
      Если оптимизировать, то вполне можно сделать проведение порциями в фоновом режиме, чтобы время блокировки регистра было не большим. Если записывать/проводить документы по 1 млн строк, то время блокировки достигает нескольких минут, и работать в многопользовательском режиме не возможно

Видно, что основная проблема - это не проведение документа, а запись. С другой стороны, если создавать документы программно, то и проблем с записью быть не должно. Короче 1 млн строк в сутки - это вполне нормально и комфортно.

(189) Как ты оставишь на сервере, один то раз все равно придется передать. А это для тонкого клиента явная смерть

(231) какая связь между 1млн документов и поэтому блокировки?

очень рационально. Чтобы изменить одну запись, перезаписывать миллионы записей

(237) в нормальных системах ничего задним числом не меняется

(233)
"можно сделать проведение порциями в фоновом режиме"
Когда не смог в ACID

(215) У Экселя - xlxb - бинарный формат. Это собственно оптимальнейший способ упаковки числовых и строковых значений. Фактически архив.
Сравнение с выгруженной базой 1с, вполне корректно, но 1с добавляет собственные структуры. Например собственный ключ. Засчет этого (в основном) и растет объем.
Сравнение с размером в СУБД MS SQL некорректно. тут надо сравнивать c *.csv - это неупакованные данные. И там еще добавлены ключи 1С.

Ну и немного про Эксель. Если в файл такого объема добавить сложные вычисления. Типа сколько продаж по филиалу, по покупателю, поиск чего-то. То пересчет этого файла... Ну обед обеспечен. )))