Всем привет!
1С сервер 8.3 в связке с MS SQL 17
База УТ 10.3

Подскажите реально ли хранить 4,5 млн номенклатуры и регулярно переписывать цены на все позиции?

И соответственно периодически формировать прайс на все позиции из базы?

Реально, правда при условии что не чаще раз в 2 недели. Быстрее я думаю не получиться.

По моим прикидкам в секунду он будет писать 3-5 позиций не больше (без учета деградации по скорости из-за большого объема данных). Соотвественно 4,5 млн он будет писать порядка 900 тысяч секунд. Или 250 часов (почти 10,5 дней).

Конкретные цифры уже нужно смотреть на вашем железе. Возможно вы будете напрямую в скуль писать и достигните скорости записи до 100 000 позиций в секунду

(0) Хвораете?

(0) Переписывать = вводить документ "Установка цен номенклатуры"?

(0) Зачем вам 4.5 миллиона номенклатуры?

(1) Обоснуйте эту цифру, пожалуйста.
Документ в 1000 строк будет проводиться по 1 (ЕМНИП) регистру в течение 3-5 минут?

(4) "почему кот я..ца лижет? потому что может"
если хранят столько - значит нужно

(1)
на современном железе писать будет 20-50 т строк в секунду в регистр.
(0)
в 2012 типовой механизм ут 10.3 не потянул  работу на чтение  1 млн - активной номенклатуры , 30 типов цен, 150 операторов.

Извините...
Десятки миллионов номенклатур... Вы там не Госплан пишете?

(7) а пересчет итогов по регистру?

видать партии засунули в номенклатуру  - да еще за несколько лет, хотя имхо и это перебор

4.5 млн ни о чем

(8) Автозапчасти, любой агрегатор "ничего на складе, но знаю у кого купить".

(1) ты на калькуляторе запускаешь 1С что ли?

(1) да, чего-то хрень какую-то пишешь. Вот у меня обработка, загружает 5000 позиций номенклатуры с ценами. База файловая. Работает где-то как раз 3-5 секунд. Откуда такие цифры про 3-5  позиций в секунду?

(14) потому что у тебя файловая на крутом проце и на ссд
а в продакшен будет древний сервер с опертронами/ксоенами с базовой частотой 2.0. причем на скуле, причем скуль и сервер на разных машинах. или на одной но на сервере всего 16 гтглв памяти и там еще 40 рыл работают


Короче я когда дома у себя пишут код он тоже за полсекунды отрабатыва, а вот в продакшене, когда 100 рыл сидят этот же код уже работает секунды 3-5

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

Ну и в режиме без замещения еще, да

(15) не повезло тебе... )

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

(13) ну просто грузил недавно номенклатуру из 7-ки в 8-ку и примерные цифры оттуда.

плюс кроме проведения есть еще поиск номенклатуры, сопоставления и куча других нюансов влияющие на скорость

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


Короче мы берем лабораторные условие (разогнаный проц, память с частотой 4400, база файловая и вся в памяти и крутые SSD) или продакшен?

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

(15) ни на каком у меня ссд. Самый обычный комп. Ниже среднего.

(23) я же написал "Конкретные цифры уже нужно смотреть на вашем железе. "

(24) ну это совсем другое. ты там создавал это справочник номенклатура с нуля. А здесь совсем другое. Один регистр сведений фактически. Думаю корректировка прайса у него займет несколько минут максимум.

(25) ну только если мы говорим про типовую, то писать он будет в документы. Причем нужно будет разбивать по 100 000 строк, иначе попа со скростью может быть. После этого нужно записать документы и они уже запишут движения

(26) 1С, вроде бы не умеет таб. часть со 100 000 строк?

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

(26) "разбивать по 100 000 строк, иначе попа со скростью может быть" // Ограничение платформы - 99 999 строк. Так что твоя ветка "иначе" неуместна :)

(27) умеет, но наблюдается очень сильная деградация. Т.е. скорость проведения 2-х документов по 100 тысяч сильно меньше чем скорость проведения одного документа на 200 000

p.s. Цифры условные служат лишь ориентиром, поэтому не надо с секундомером бегать и доказывать что нет разницы между проведением 100 000 строк и 100 001 строка

(30) можно по 1000 строк на документ. Так в 100 раз быстрее будет, чем 100000. Теперь понятно, почему у тебя тормозит. У тебя один документ на всю номенклатуру, 100000 строк. И если пользователю нужно подправить в нем одну строчку, то этот документ целиком переписываешь.

(9)  прямым запросом. и на копии.

(31) у меня нет такой задачи (загрузить 4,5 млн цен), поэтому у меня не может тормозить то, чего нет

но со скоростью проведения отчетов по комиссии в типовой БП 3.0 на 15-20 тысяч строк я намучался. Нажимаешь провести и идешь курить бамбук, пока он все проверки сделает и сформирует движения, попутно блокирую базу.

(34) в бух 3.0 надо регламентные задания все отключить. там по умолчанию всё включено.

(35) мусор отключил, остальные раскидал по времени когда все спят

Ещё на 1с77, торговля и склад, было несколько складов, несколько млн ед хранения, это металлы, покупные изделия, типа резисторы, транзисторы. Номенклатуру разбивал на группы, делал контекстный поиск. Как сейчас, на 1с8 не знаю.

(3) Да именно

(22) Использую механизм создания документов установка цен, через обработку. по 25 тыс строк в документ

1С на такие обьемы не расчитана. И вопрос тут даже не только в загрузке но и обычной работе.
Крутить отчеты и тп и тд.
Даже тупо что то искать в справочнике через поиск.

Обычно автозапчастники держат базы данных напрямую на сайтах на спецдвижках и мощностях.
А в 1С попадает только рабочая номенклатура, т.е конкретная по которой прошел заказ/продажа и тд.

(41) Спасибо, очень важный комментарий

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

(40) поиск на 2 млн номеклатур уже подтормаживает

К тому же автозапчастей даже не 5 миллионов, а кабы не 50-80

И все что продается зачастую разовое.

Крутили отчеты в базе по 500 000 позиций которые проходили по продажам за несколько лет, ставили условие - выкпутить позиции которые продаются в каждом месяце.

Выходил отчет на 2 000 позиций всего.

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

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

Все остальное, имеет смысл грузить только напрямую на сайт.
И работать с АПИ-шками поставщиков, в автозапчастях практически все они с веб-сервисами.

(40) Может не 1С, а типовые конфигурации? Все в итоге в запросы к СУБД приходит и надо просто грамотно настроить?

(45) у нас специфика такая, что более 5 млн не будет

+(45) и то грузили такие прайсы исключительно для анализа цен поставщиков и закупки на склад.
Плюс наиболее ходовые позиции. По которым можно пополнить склад по самым выгодным ценам.
Все остальное что под заказ . 1С лопнет.

(48) да пофигу. создай хоть справочник с двумя реквизитами.
Справочник Номенклатура постоянно открываемый справочник. Подборы, цены, остатки и прочее.

(49) ну и явно это не 1 поставщик, а десятки. В которых наверняка по 20-50 тыщ позиций. а не все 5 миллионов.

один фуй. остатки постоянно меняются.
Загружать одно, потом еще на сайт выгружать это все. Даже если не цены, так остатки плясать могут каждую минуту.

постоянное изменение цен, остатков. регистрация этого всего. перегруз и обмен с сайтом.
От типового обмена наверное нафиг сразу придется отказаться.

Делать текстовые файлы обмена, csv или еще что то облегченное.
Самописные обмены и прочее.
в XML это просто нафиг выйдет в нехватку памяти.

Прайс в 800 000 строк при загрузке в 1С жрет 5 гигабайт памяти и проц на 4.5 долбит.

(53) Понял, спасибо

переоценку делать только фоном с автоматическими правилами.
никаких интерактивных действий ни с чем.

(44) притормаживает - это в секундах сколько, интересно?

подбор переписать на форм где только поисковая строка и пустая таблица. никакого списка.
по поиску запрос и выкатка в ТЗ то что попало с остатками и ценами.

я уже давно хотел написать такое рабочее место. где никаких списков. а поисковая строка и ниже таблица.

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

вот хорошо что вспомнил! ща его и начну делать

(50) (57) (58) - вот это я и назвал "просто грамотно настроить".

(58) Мы такое делали на 77. Быстро, но главная задача была - лишить ушлых менеджеров возможности видеть лишнее. Ни один справочник был им недоступен.

(56) примерно 30

Маня пришёл, расставил все точки над и :) Крутыш такой, в теме :)

(63) Надо, чтобы в его обработке по загрузке цен можно было указать пути к базам.. Пусть Маня помимо самой обработки предоставляет еще и собственные ресурсы по чтению и обработки файла.

(64) это не оправдается, так как таких жирных клиентов с такими обьемами раз-два......

трудозатраты на усложнение массового продукта которые охватят лишь разовых клиентов. не эффективны.