Вход | Регистрация
    1  2  3
1С:Предприятие :: 1С:Предприятие 8 общая

Ограничение в табличной части документа 99 999 строк

[catena, 25.10.19 - 11:00]
Ограничение в табличной части документа 99 999 строк
Я
   ProxyInspector
 
24.10.19 - 17:20
1с8.3.9
Надо заполнить оборотный регистр данными.
Неожиданно столкнулся с ограничением на размер табличной части документа в 99 999 строк.
Можно ли это обойти.
И как заполнить регистр большим объемом данных, используя 1с Предприятие 8?
 
 
   ProxyInspector
 
201 - 09.01.20 - 10:32
Эта задача не есть какое то новое слово в 1С. Просто интересно посмотреть как ведет себя 1С на больших объемах информации.
Зачем такие документы? Задача такая.
   pechkin
 
202 - 09.01.20 - 10:33
(198) пиши сразу в регистр, зачем проведение?
   sqr4
 
203 - 09.01.20 - 10:34
(201) а почему делали табличные части, а не сразу вывели движения документа для редактирования, по нужному регистру? Думаю время бы сэкономили.
   080808Ник
 
204 - 09.01.20 - 10:34
(194) а зачем два лишних действия? имитация табличной части, проведение по регистру? чего сразу не грузануть в движения?
   pechkin
 
205 - 09.01.20 - 10:37
(203) если вывести 1кк строк движений для редактирования то клиент умрет
   ProxyInspector
 
206 - 09.01.20 - 10:37
В табличной части еще сырая информация. Не привязанная к справочникам базы. В регистре уже причесанная информация. И хочется хранить исходную информацию. В этом случае можно делать фоновую обработку, проведение документов.
   pechkin
 
207 - 09.01.20 - 10:38
в твоем случае лучше эмулировать ТЧ через рег сведений
   ProxyInspector
 
208 - 09.01.20 - 10:39
В данном случае работа в тонком клиенте даже не рассматривалась. Тонкий клиент умирает уже на уровне 50 тыс строк. В толстом все более менее нормально. Просмотр движений дркумента на 1 млн. вполне работает.
   1Сергей
 
209 - 09.01.20 - 10:44
(206) т.е. человек руками будет актуализировать миллионы строк в документе?
   ProxyInspector
 
210 - 09.01.20 - 10:44
Короче за достаточно короткое время удалось залить в базу 100 млн строк. И посмотреть как работает СКД с такими объемами информации. Изначально я как то скептически был настроен по поводу СКД. Здесь 1С меня приятно удивила. СКД вполне работоспособен. Видно было, что SQL уже подтормаживал. Если сделать отчет по всем записям, с разбивкой по периодам, то при первом запуске отчет выполняется где-то секунд 30-60. После этого SQL таблицу в кеш, и после этого время выполнения в любых разрезах - несколько сек.
   ProxyInspector
 
211 - 09.01.20 - 10:46
(209) Да. Это вполне реально. Типа привязать к нужному контргенту, номенклатуре, проверить корректность заполнения. Отбор, групповая обработка строк. Я так обработал 100 млн. строк :)
   ProxyInspector
 
212 - 09.01.20 - 10:52
Что порадовало в 1С при обработке больших объемов данных
1. Работа кэша. 1С научились немного работать с кэшем. Было видно, что кеш корректно выделялся и чистился как на клиенте так и на сервере
2. 1С может работать с такими объемами данных
3. СКД можно использовать для отчетов по большому количеству данных
   pechkin
 
213 - 09.01.20 - 10:54
(212) скд на вывод 100 млн строк или для обработки?
если для обработки - это все сиквел, а для него 100кк не особо много
   Кац
 
214 - 09.01.20 - 10:57
(212) версия платформы?
   ProxyInspector
 
215 - 09.01.20 - 11:04
Что огорчило в 1С
1. Отвратительное использование памяти.
Исходный файл EXELL в 1 млн строк занимает 30 мб. При прочтении этого файла в таблицу значений 1С требуется уже 8 ГБ оперативной памяти. Exell открывает это файл за 10 сек, 1с открывает документ с этими данными в районе 1 мин.
Exell требуется 150 мБ для работы с этим файлом 1с - 8 Гб
2. Глубокая однопоточность 1С. В моем случае было жестко видно, что 1С работает строго в один поток. Даже если использует несколько ядер. У меня 4 ядра, и видно было стандартная суммарная загрузка 25% при этом загрузка плавно перемещалась с одного ядра на другое.
3. Плохое использование диск. 1С насилует диски по черному
   ProxyInspector
 
216 - 09.01.20 - 11:09
Платформа 8.3.9.2233 толстый клиент. Конфигурация десяток справочников. Один документ. Один регистр сведений с табличной частью. Один оборотный регистр. Один СКД отчет. НИкаких БСП. Размер конфигурации нескоько мБ
   ProxyInspector
 
217 - 09.01.20 - 11:13
Размер базы данных SQL - 120 гБ. Размер выгрузки базы 10 гБ. Самое интересное что размер этих же данных в Exell - 4 Гб в формате .xlsb
   pechkin
 
218 - 09.01.20 - 11:14
(215) ну многопоточность нужно ручками писать вообщето
   ДенисЧ
 
219 - 09.01.20 - 11:18
(215) Переходи в фузину, там такого нет. И перестань плакаться тут.
   ProxyInspector
 
220 - 09.01.20 - 11:20
Напоследок:
У меня получилось в районе 120 документов на 100 млн строк. Групповая обработка и проведение  всех этих документов занимает в районе 1 суток. В один поток, в несколько потоков не получается, так как нарывается на блокировки. Для проведения и обработки требуется минимум 8 Гб оперативки как на клиенте так и на сервере. Ну и с большой долей вероятности эта обработка завалит сервер 1С  :)
   ProxyInspector
 
221 - 09.01.20 - 11:22
(219) Фузина сказала, что им такое не под силу без привлечения сторонних разработок. Здесь же все штатными средствами 1С
   ДенисЧ
 
222 - 09.01.20 - 11:24
(221) Ты сидишь и плачешься на штатные средства 1с, не сделав ни единого шага, чтобы это исправить. И кто тебе после этого доктор?
   ProxyInspector
 
223 - 09.01.20 - 11:27
(222) А зачем мне это исправлять? Здесь нет задачи активно работать с этими данными. Задача сделать десяток раз отчеты маркетологом. Раз в месяц за 30 мин добавить месячные продажи всех федеральных сетей. И забыть об этом. А вот увидеть границы использования 1С данная задача вполне позволяет
   ДенисЧ
 
224 - 09.01.20 - 11:28
(223) Границы твоего ограниченного разума, а не применения 1с.
   sqr4
 
225 - 09.01.20 - 11:29
(222) да вроде не плачется он, а рассказывает как и что работает
   Кац
 
226 - 09.01.20 - 11:31
(221) А как же заявление фузиновцев о мильонах строк в документах? и трех строк кода?
   sqr4
 
227 - 09.01.20 - 11:35
(226) ну это они могут, а вот отчеты не умеют, только би покупать
   ProxyInspector
 
228 - 09.01.20 - 11:36
Фузиновцы сказали, что они могут обработать мрд. строк, но с помощью DRUID. При этом этот млрд. это не наш 1 млрд, а 1 млрд строк с учетом итоговых записей по измерениям регистра.  Т.е их млрд - это наши 100 млн
   ProxyInspector
 
229 - 09.01.20 - 11:38
Интересно было бы посмотреть размеры таблиц 1С по моим 100 млн. записей, но не работает SQL menegment Studio
   ProxyInspector
 
230 - 09.01.20 - 11:44
Ограничения по многопользовательской работе в 1С можно оценить как 1 млн движений по всем регистрам в сутки. Или где-то 100 000 строк документов в сутки. Или 10-20 тыс документов в сутки. Это соответствует небольшой сетки магазинов или одного магазина на 100 касс.
 
 Рекламное место пустует
   Sammo
 
231 - 09.01.20 - 11:45
Меня расстраивает следующее: реальная ситуация - у клиента под 1 млн операций в день. Каждая операция - это приход/расход денег и расход/приход товара.
И получается 2 крайности и один промежуточный вариант:
1. Документ с 1 млн строк, который будет делать проводки по регистрам денег и товаров. Но есть ограничение на количество строк в табличной части, а значит приходится делать регистр сведений, который подчинен регистратору и хранит информацию об операциях, но делает записи по регистрам более-менее быстро (ибо сразу есть вся выборка).
2. 1 млн документов с одной операцией, которые проводить приходится по одному (т.к. 1с не умеет писать наборы регистров накоплений по разным регистраторам), а значит даже при параллельном проведении возможны блокировки. Я уж молчу про регистрацию в плане обмена.
3. Промежуточный вариант - дробить документы по 5/50/100 тысяч строк. Но когда вдруг надо исправить 1 операцию - ты сначала найди ее в этих документах.
И шо тут сделаешь?
   la luna llena
 
232 - 09.01.20 - 11:47
(224) всё по делу, конкретно с цифрами, интересно.
   ProxyInspector
 
233 - 09.01.20 - 11:54
(231) Из за этого и пришлось городить документ в 1 млн. строк. Одно дело 200 документов в 1 млн строк, другое - 20 000 документов по 10 000 строк.
      Если оптимизировать, то вполне можно сделать проведение порциями в фоновом режиме, чтобы время блокировки регистра было не большим. Если записывать/проводить документы по 1 млн строк, то время блокировки достигает нескольких минут, и работать в многопользовательском режиме не возможно
   ProxyInspector
 
234 - 09.01.20 - 11:57
Видно, что основная проблема - это не проведение документа, а запись. С другой стороны, если создавать документы программно, то и проблем с записью быть не должно. Короче 1 млн строк в сутки - это вполне нормально и комфортно.
   ProxyInspector
 
235 - 09.01.20 - 12:25
(189) Как ты оставишь на сервере, один то раз все равно придется передать. А это для тонкого клиента явная смерть
   pechkin
 
236 - 09.01.20 - 12:26
(231) какая связь между 1млн документов и поэтому блокировки?
   1Сергей
 
237 - 09.01.20 - 12:34
очень рационально. Чтобы изменить одну запись, перезаписывать миллионы записей
   pechkin
 
238 - 09.01.20 - 12:38
(237) в нормальных системах ничего задним числом не меняется
   H A D G E H O G s
 
239 - 09.01.20 - 12:40
(233)
"можно сделать проведение порциями в фоновом режиме"
Когда не смог в ACID
   Ювелир
 
240 - 09.01.20 - 13:14
(215) У Экселя - xlxb - бинарный формат. Это собственно оптимальнейший способ упаковки числовых и строковых значений. Фактически архив.
Сравнение с выгруженной базой 1с, вполне корректно, но 1с добавляет собственные структуры. Например собственный ключ. Засчет этого (в основном) и растет объем.
Сравнение с размером в СУБД MS SQL некорректно. тут надо сравнивать c *.csv - это неупакованные данные. И там еще добавлены ключи 1С.

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

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.