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

дробить не вариант? пиши в рс

У меня там 30х500 тыс строк. Всего то 15 млн.

(1) Дробить можно. Но сам документ не сохраняется.

Зачем это хранить в ТЧ?

(0) > Неожиданно

Неужели?

> И как заполнить регистр большим объемом данных, используя

2 документа?

А где хранить весь этот мусор?

(6) В регистре сведений.

15 млн строк по 5000 строк на документ, неужели тяжко сгенерить 3000 доков. Да и разбираться с частями в случае чего быстрее и проще, чем распроводить док на 15 млн строк.
Или тебя фузиновцы укусили?

(6) Если это мусор, то в мусорке. Зачем мусор в 1с пихать?
А если серьезно, то прямо в регистр и писать, а не в тч добавлять. Если нужен корректный регистратор, то создать служебный и его указать.

(6) сразу писать в оборотный регистр

(6)
1. Писать напрямую в регистр.
2. В макете.

корректировка регистров вполне справится

(2) можно 30 документов по 5 табличных частей в каждом

(10) Это интересно. В этом что-то есть. Писать напрямую в оборотный регистр. Благо на форме документ позволяет заполнять 500 тыс строк

(0) пиши в движения документа, накуя тут ТЧ

(0) Издеваетесь ? Кому нужны документы больше 10К строк ?

ПриЗаписи пишем в оборотный регистр, а ПриОТкрытии заполняем

(16) ты не в теме, не познал ещё дзена 1С

(14) Ты реально руками их собрался бить? какая разница то на форме?

(17) Типовая операция/КЗР делают это "из коробки"

(16) Есть большой объем данных. Продажи мелкой сети типа Дикси. Надо грузануть их в 1С для анализа. Один файл за один месяц 500 тыс строк. Это еще не весь ассортимент.

(14) посмотри как работает документ ОперацияБух

А что такое КЗР?

(21) есть такое решение - мегапрайс назвывается, он вроде в это умеет)))
(23) Корректировка записей региста

(14) Форма нужна только людям. Но я не знаю тех, кто будет просматривать мильон строк с экрана. Мазохизм однако..

(23) В конфигурация отличных от БП "корректировка записей регистров"

(22) А что документ "Операция Бух" умеет хранить более 99 999 строк?

(27) Он может хранить сколько угодно строк.
Ты просто посмотри что это за документ)

(27) ОперацияБух только регистратор, а смотришь ты в регистры

(27) данные хранятся в регистре. Документ выступает регистратором. Проведения нет

Уже 28 сообщений и ни одного переходить на фузину. Непорядок.

(27) ты не поверишь

(31) Да просто нафиг она никому не нужна

(30) Это интересно. Мне нравится

(31) ты за фузину ответь на вопросы, куда слился?

(34) и даже в этом случае советую дробить на кусочки.

Но как то странно, ТаблицыЗначений, СпискиЗначений  научились делать более 100 тыс, а табличную часть нет.
А что Фузина умеет хранить более 100 тыс строк?

(36) Форма документа на 500 тыс. строк достаточно шустрая

Проведение документа 100 тыс строк - 10 сек, тоже приемлемо.

(38) кто будет просматривать мильон строк с экрана?

(37) Это специальное ограничение.
Счтается, что если тебе надо более 100К строк в ТЧ - то у тебя беда с архитектурой

Что за странная тяга тащить всякий мусор в базы 1с? Ну загрузи в любой внешний источник, подключи в 1с и анализируй на здоровье!

(37) табличная часть документа на такое количество строк - методологичекская ошибка.
1С сама рекомендует при таком количестве строк выполнять запись напрямую в регистр, не используя ТЧ, как с документом операциябух.

(39) Если про операцию, то это не проведение. Перезапись набора регистра

А зачем их просматривать?

(0) Даже, если писать КЗР, рекомендую, разбивать весь массив на несколько документов. Иначе при объединении дубля контрагента, например, можно неожиданно записать набор в 15 млн записей.

(45) Так это ты про быстроту формы рассуждаешь

(37) фузине фиолетово, она ничего не ограничивает. Там все динамические списки.

Глянуть если что.. Проверить, что все реквизиты заполнены. На сколько я понимаю, в регистр сведений не добавишь дополнительные реквизиты

(48) Я тоже думал, что 1с8 фиолетово. Но оказалось, что не так. У меня еще толстый клиент. А "тонкий" клиент у меня умирал задолго до 100 тыс. строк

(48) забавно что врятли ктото проверял этот факт фиолетовости, в реальности внезапно начнут вылезать всякие ограничения кешей и т.п.

Формировал движения сразу по регистру через Корректировка записей регистров. Но не 15 миллионов, а поменьше.

(51) *например видел в реальной системе трабл схожий где разработчики не знали что есть ограничения, там форма генерила запрос который не влезал в запрос БД...и они долго не могли догнать почему...в итоге отделались пунктом в мануале в стиле 'а вы не делайте много строчек в документе'

(51) в соседнюю ветку зайдите. Там конечно флейма и флуда вагон, но как раз обсуждалась с примерами эта проблема.

А у фузины табличная часть это просто объекты (строки) с ссылкой при обнулении которой удаляется сам объект (строка в данном случае)

(54) неохота ковырятся там.... но использовать напрямую orm с большими объемами данных это уже заявка на победу

(54) Это не табличная часть. Это регистр сведений с ведущим измерением в терминах 1С.

(45) Если незачем просматривать, то не нужен документ и форма к нему.
Достаточно иметь только документ как регистратор без всяких ТЧ

(55) там нет orm все не на сервере приложений, а наоборот делается на уровне СУБД.
(56) строго говоря в 1с непериодический регистр сведений и есть просто таблица с ключами. Что конечно жесть не очевидно.

(58) Что конечно жесть не очевидно.
Какие ещё могут быть варианты? Вроде как раз очевидно

+(59) https://its.1c.ru/db/v8devgloss#content:20:hdoc:03

"Регистр сведений
Прикладной объект, предназначенный для хранения произвольных данных в разрезе нескольких измерений. В том числе в разрезе времени.

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

(59) а теперь представьте что вы объясняете это кому то кто не знает 1с. Помните тот фильм про расизм, где в конце адвокат говорит: а теперь представьте что эта девочка белая.

(61) А зачем объяснять тем кто не знает 1с?
Это отраслевой форум.

(62) не это так, мысли вслух. Не обращайте внимания.

Пиши сразу в движения, без ТЧ

(64)+1, в типовых даже док для этого есть.

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

В клюшках было много не логичного (типа объект Периодический), в снеговике структура как раз прозрачна и логична.

(54) Как отрабатывается сценарий "редактировал-редактировал, набил 100 строк, потом закрыл без сохранения"?

Я бы  хранил все ТУПО ВО ВНЕШЕМ CSV ФАЙЛЕ и читал бы его и делал бы все что угодно ПОТОКОВЫМ ЧТЕНИЕМ в 1С.

У меня есть такой файл ровно в 15 000 000 строк. Потоковым чтением он весь построчно перечитывается 1Ской за 1 минуту.

Я думаю это будет быстрее чем пихать все это в 1С - что нерально, да еще потом сто пудово в 1С какие то фигни использовать. Когда тупо извне CSV будет в потоком чтении просто влет работать.

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

(54) > в соседнюю ветку зайдите

Бродит дурачок^wфузиновец по лесу^wфоруму, ищет дурачок^wфузиновец глупее себя...

(21) те у тебя в отих отчетах данные по продажам? Тем БОЛЕЕ через (68).

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

Очень легко потоковым чтением все 30 файлов перечитать и сразу сделать отчет - хоч в 1С, хоч сразу во внешний файл. Хоч можно даже свои данные добавить.

Я две обработки таких сделал для CSV
Одна умеет перечитывать и редактировать файлы любого размера / резать их / фильтровать.
Вторая умеет брать кучу файлов и делать сводную таблицу.

(71) чм стандартные внешние источники с текстовым драйвером не угодили?

ну вот реально, и чтение и запись и черт лысый

и даже отчеты на СКД без извращений

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

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

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

(0) Кто источник данных-то?
Не пользователи же сгенерили 15 лимонов строк

(21) А, сорян, не заметил
Ну так не извращайся, сразу в регистр и пиши, ты же не будешь их через ТЧ редактировать
Создай регистратор без ТЧ и к нему присобачь 15 лямов записей набором записей

Увидишь Бро, плюнь ему в спину, у нас так принято

(77) ну вот ты переделай на внешние источники данных и посмотри, сколько времени ты сэкономишь на работе алгоритма, а главное - на разработке того, как с этим работать из 1с. Или точить как всегда некогда, пилить надо? Технологии, если что, более 20 лет.

(0) Пиши сразу в регистр.
Запись порциями по 25000-50000 элементов в  1 транзакции. Перед этим установи УстановитьИспользованиеИтогов  в ложь после записи включи.
15 млн строк загрузятся очень быстро.

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

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

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

(81) Правильно. Пусть юзвери прихиреют.

(42) о, да это любимое дело для серьезных фронт и репорт систем

(66) в клюшках периодические реквизиты - для юзверей совершенно понятны и прозрачны.
для программиста - если он пОГРомист 1С - может и нет...

(81)
Borteg отключает итоги.
Юзеры в системе: https://pbs.twimg.com/media/D7jzZLPX4AAGm7h.jpg

И.. нахрена грузить в останковый регистр.. еще и итоги отключать ?

(87) с пользователями понятно. Адекватный прог тоже во всём разберётся и даже привыкнет. Тем не менее решение хранить периодические значения вместе с константами никак не выглядит логичным. Несколько способов работы (Объект.Периодический/Реквизит.Установить/ИспользоватьДату)с этими сущностями тоже не выглядят логичными, а скорее ситуативными

Ну вопрос и вопрос на засыпку старому клюшечнику

Спр.ИспользоватьДату(Дата1);
Спр.Записать();

создаст записи на дату по каждому периодическому реквизиту?

В общем после этого (привычного уже на тот момент) треша, РС в восьмерке просто образцом логичности были.

(90) а то что в 8-ке один и тот же код можно запихать в ряд мест - это не напрягает. это тоже ситуативно.

(90) "создаст записи на дату по каждому периодическому реквизиту?"
не берусь утверждать 100% - но да.

(90) РС конечно вещь нужная.

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

(94) конечная задача - повертеть плоские данные по разным параметрам. для этого 1С непрвильно юзать (так говорят боги фузины). следует выгрузить массив в BI в любое облако и там обкрутить хоть обкакатьяс с туевой хучей готовых сценариев обработки и отображения.
.
я бы кстати на месте ТС так и попробовал сделать.

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

я больше чем на 1000000 процентов знаю что такой обьем информации не способен переработать яеловек чтобы оно ни было.
значит на тот же миллион процентов есть явно выраженная конечная цель, которая явно является конечной задачей с полным перечнем условий

Может оказаться что ему в итоге из всего этого вообще 1000 строк нужна а все остальное нафуй.

Как пример мне тоже заказчик пришел сначала нес фигню. Но когда я начал задавать вопросы наводящие, то оказалось что из 15 миллионов строк ему нужно всего то получить несколько тысяч с конкретными условиями.

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

(97) вот тебе тупо конечная задач.
массив данных как у (0).
определить, что является явным признаком (или совокупность признаков) товара(ов), влияющим на объем продаж.

мне нравится вариант (42)

(97) Маня не умеет в BI :))

15 млн строк это это оборотный регистр Продажи за 1 год. За несколько лет будет 50 млн. И что то меня мучают сомнения, не будет ли тормозить СКД на таких объемах.

Задачка, загрузить данные по продажам крупнейших Федеральных сетей. И сделать аналитический отчет по этим продажам. Интересно справится ли 1С с этой задачей

(104) Будет, инфа 100%.

(105) Не правильный инструмент использовать хочешь ты :))

(107) Чем богаты. 1с наше все. Или все таки надо переходить на Фузину для таких задач :)

(108) Начни с Кликвью :))

(105) 1С справиться-то

(88) (85) от чего юзвери мучаться то будут? от отключения итогов на пару минут в самописном регистре, пользоваться которым возможно только после загрузки данных?

(104) не будет, у меня в регистр каждый месяц грузится по 15-20 млн записей. Работает все отлично.

(105) такие вещи с полпинка делают в оракле пока пьют коффе,
но так как он в опале то барахтайтесь в 1С денно и ношщьно.

(113) В голом оракле? Или таки с олапом?

(113) Осталось дело за малым. Купить Оракл и Олап

(105) 1с не рассчитана на большие объемы данных. 1С была, есть и будет платформой для автоматизации учета.

(116) Печально. Но учет учету рознь. У нас в управленческой базе несколько млн. документов. И тоже там учет.
Тогда надо писать "1с не рассчитана на большие объемы данных. 1С была, есть и будет платформой для автоматизации учета ЛАРЬКОВ"

(117) При таких объемах учёт и отчеты лучше делать в разных базах :))

(118) А смысл какой?  Оборотный регистр на 50 млн записей занимает пару гигов памяти. Это совсем мало. Из за этого городить новую базу? Или ставить Оракл и Олап. Как то это не солидно. И все это из-за того, что 1С посчитало, что для ларьков нет необходимости иметь табличные части больше 100 тыс строк.

(116) Расчитана

А большие объёмы у вас это сколько? А то видел базку в 1.5 ТБ. И ничего, крутилась.

(105) а теперь ответь на главный вопрос - какой дибил будет листать этот отчет?

Я уже написал что такую информацию визуально не состоянии переварить человек. Поэтому ты не договариваешь задачу.
Нужно конкретно знать условия фильров продаж. И ихз применить на этапе загрузки.

Иными словами я бы сразу импортировал и обрабатывал ТОЛЬКО то что нужно

(119) А смысл такой, что в типовых тормозить будет одновременная работа учёта и отчетности. В самописке, конечно, можно сделать нормальную архитектуру, но не все на это способны.

(119) ограничение в 100 000 строк есть, но тут уже 20 раз повторяли что ты можешь делать не 1 а много документов.

(120) Платформа или типовые :))?

Как то раз делал на восьмерке базу для анализа - в которую выгружал обороты продаж и срезы остатков. Конфигурация исключительно была заточена для получения определенных аналитических данных и создавала планы продаж и закупок.
Основная база была вообще на семерке.

(122) Почитай хоть про BI системы, не позорься.

(127) сьешь конфетку

(128) Не хочешь? Ну продолжай писать наивную чепуху, тогда.

(129) чепуху тут пишешь пока ты. с нулем полезной информации. ровно НОЛЬ

(130) Ну, сочувствую тебе, что сказать ещё.

Чтобы мы имеем

Большое количество файлов по 500 000. В них обороты продаж.

Какие проблемы будут при импорте в 1С

1) Раз это продажи, то наверняка там есть как МИНИМУМ - номенклатура, партнер, склад. А это справочники в 1С.
Поэтому первостепенно появится неизбежно первая составляющая - синхронизация.
Сопоставление текстовых данных файла с ссылками справочника.

Если он начнет искать все построчно - то будет тормозить.
Если будет обрабатывать 500 000 в запросах - тоже будет тормозить.

По факту ему нужно по каждой строке получить кучу ссылок справочников в 1С чтобы получить таблицу для заполнения в документ.

2) Запись в 1С в оборотный регистр продаж - по сравнению с пунктом 1) менее тормозная вещь. Никаких проблем - загружает и записывает данные по 99 999 строк в оболротный регистр.

3) Получение ответов из 1С - будет сильно тормозить, так как планируется от 15 и далее по нарастащей миллионов записей.
Хорошие серваки от полумиллиона рублей.

4) Предположим менеджер выкатил отчет из 1С в который попало 200 000 строк из 15 000 000. Что он собирается с этим делать? Листать? да ну нафиг.

(131) себе сочувстсвуй недалекий.

(48) реально ржу о таких комментов )))
Вот "упорные" ребята

https://a.d-cd.net/63e73bas-960.jpg

Я ьы выделил из перечисленного 1) и 4).
Так как то что в (0) это детский лепет по сравнению с тем что имопртируемые данные для 1С нужно синхронизировать для начала, прежде чем даже в документы запихивать. и ограничение в 99 999 строк это вообще тут никакой роли не играет.

А Маня такой-же упёртый, как фузиновцы. Они бы сработались, однозначно :))

(137) У фузины одна беда - там только склад есть, и тот кривой. А так - хоть 100тыщминьенок загружай.

(138) У фузины интеграция с каким-то бесплатным БиАем, фузину выкидываем, БиАй оставляем - профит :))

чтобы сделал я

1) потоковое чтение и деление файлов на более мелкие файлы по 99 999 строк (резка файлов)
2) подгрузка файла в ТЗ 1С, с единым запросом который синхронизирует записи и выдает результат в ТЗ
3) создание доп документа (своего, а не типового) для проведения по регистру продаж 1С. Загрузка в него ТЗ и проведение.

Также немалую роль играет какая конфигурация 1С. так как в УТ11 регистра продаж нет, там есть выручка и себестоимость. И это ужасный регистр, потому что там пара десятков измерений. И может оказаться что в импортируемых данных просто даже дофига чего нет из того что там нужно.
А также то что номенклатура и партнеры - в этом регистре это еще справочники но не номенклатура и партнера, и ключи аналитик....
А это значит что база еще больше засрется.

(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С.

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