Имя: Пароль:
1C
 
Организация регистров под большие объемы данных.
0 Kongo2019
 
16.10.19
15:48
Доброго.
У нашей дружественной организации, есть отраслевая конфигурация.
Но они на сегодня столкнулись с проблемой. Большие задержки по обработке документов, отчетов и прочего.
Мы свое время, глянув на эту реализацию, прогнали несколько тестов, сказали нафуй. И сделали отдельный блок не на 1С. На 1С мы не осилили. Сейчас надо сделать на 1С.
У них все это сделано на одном регистре сведений, который еще и подчинен регистратору, девять видов документов. На текущий момент, при общем размере БД в 50 гигов, только этот регистр 14 гигов. В общем, печально все.
Структура регистра такова.
Измерения
- Марка – тип строка 160
Ресурсы
- Упаковка - тип строка 120
- Справка – тип СправочникСсылка.алкКлассификаторСправокАиБ
- АлкогольнаяПродукция – тип СправочникСсылка.алкКлассификаторАлкогольнойПродукцииЕГАИС
- Организация - тип СправочникСсылка.Организации
- ПунктРазгрузки - тип СправочникСсылка.алкПунктыРазгрузки
- ОтметкаВыбытия – тип булево

На текущий момент обсуждается вынести это в отдельную базу. Но надо как-то оптимизировать. Если перенести 1 в 1, задница все равно догонит.
Объемы будут только расти.
В общем, рад любой идее.
Может это регистр как-то сжимать периодически.
1 Cyberhawk
 
16.10.19
15:50
1. Не хранить данные в документе, прямая запись и чтение из регистров.
2. Для максимально возможной быстрой записи в регистр (прямой инсерт) использовать запись через НЗ в режиме загрузки и без замещения.
2 toypaul
 
гуру
16.10.19
15:50
"И сделали отдельный блок не на 1С" надо начать с того как сделали вы. тогда можно достаточно просто рассказать как сделать на 1С
3 1Сергей
 
16.10.19
15:51
ХранилищеЗначения? не, не слышал
4 Kongo2019
 
16.10.19
15:54
(1)
Так данные в доке вроде и не хранятся.
Меня больше чтение интересует.
5 Ёпрст
 
16.10.19
15:56
(0) кт-ая конфа она да, такая..
:)
6 Ёпрст
 
16.10.19
15:56
(4) чтение ? Может запись в этот монстр, не ?
7 Kongo2019
 
16.10.19
15:56
(2) Не хотят. У нас голый скуль и клиенты на С#.
8 Kongo2019
 
16.10.19
15:57
(5) Да блин. Догнали меня они все же. Как я не хотел с ней связываться.
9 Ёпрст
 
16.10.19
15:59
Поможет только, независимый рег сведений, марку загнать в элемент справочника и в измерении - ссылку, упаковку - аналогично.
10 Kongo2019
 
16.10.19
15:59
(6) Запись тоже нужна. Но запись пока вроде терпит. Но если есть мысли, то буду признателен.
У них начались проблемы с ТСД, тормоза.
11 ИУБиПовиц
 
16.10.19
16:01
НАверно база пухнет от того что измерение строка.
Нельзя марку и упаковку справочником сделать (пусть чисто  с одним наименованием)?
12 Kongo2019
 
16.10.19
16:01
(9) С упаковкой согласен. А марка какой смысл? Она уникальная. в 1С ссылка гуид, особо ничего не выиграем.
13 Злопчинский
 
16.10.19
16:01
(9) присоединяюсь
14 Ёпрст
 
16.10.19
16:02
(12) ссылка намного короче. чем строка 160, не говоря уже об индексе
15 Злопчинский
 
16.10.19
16:03
я не спец, но мне сомнительно что в ресурсах ряд то, что ябы поставил в измерения.
16 Злопчинский
 
16.10.19
16:04
на фузину еще можно перейти. заодно стрясешь денег с фузины за обчуение что к чему.
потом поделишься.
17 Kongo2019
 
16.10.19
16:06
(14) Ваша правда, 32 символа против 160. Плюс марка, в этом регистре накопления, не уникальна.
Каждый док пишет ее.
То бишь у меня, в идеале, минимум две записи.
Приход и расход.
А если ее туда сюда погоняли, с десяток может быть.
18 Kongo2019
 
16.10.19
16:08
(16) Вот только про фузину не надо. Я закивал удочку боссу. Он сказа по 1с спецы если что есть, по С шарпу тоже найдем. А эту хрень не надо. кто ее пилить будет если чего.
19 Ёпрст
 
16.10.19
16:08
От тут советую почитать, там понятно, надеюсь ставить, как должен быть слеплен рег сведений, где индекс воткнуть и где самая быстрая запись будет

http://catalog.mista.ru/public/527518/
20 Провинциальный 1сник
 
16.10.19
16:08
(0) "Измерения - Марка – тип строка 160"
Сделать справочник Марки, в нём наименование длиной 160, а в регистре измерением ссылку.
21 Kongo2019
 
16.10.19
16:09
Хорошо если сделать регистр независимым, то как сохранить историю?
История движения марки нужна.
22 Kigo_Kigo
 
16.10.19
16:11
ИМХО все это надо запихивать в регистр накопления и измерением - ОтметкаВыбытия – тип булево = количество,на остатке - 1 есть 0 выбыло, тогда регистр будет закрываться, и регистр сведений так и будет пухнуть по сути - справизник же
23 Ёпрст
 
16.10.19
16:11
(21) ответ же очевиден - в измерение ссылку на док
24 Kigo_Kigo
 
16.10.19
16:11
измерением  = ресурсом
25 Провинциальный 1сник
 
16.10.19
16:13
И ещё, по-моему, регистр нуждается в нормализации, слишком много ресурсов связаны с маркой. Есть смысл в декомпозиции на несколько регистров по логике изменений данных, чтобы при изменении одного ресурса не производилась запись всего набора. Ну и марка это справочник должен быть, само собой.
26 Ёпрст
 
16.10.19
16:13
заместо ОтметкаВыбытия , число с 1.0,  0 - ттн поступила. 1 - акт подтвердил ттн, -1 - товар продали/списали/переместили..

В любой момент можно грохнуть записи лишние, те что на остатках нет. Есть вся история, есть все остатки.
27 тарам пам пам
 
16.10.19
16:14
Объясните, почему марку обязательно справочником делать. Один черт же будет сначала поиск элемента справочника по наименованию с использованием почти такого же индекса, как и для регистра.
28 tesseract
 
16.10.19
16:19
>> сделали отдельный блок не на 1С. На 1С мы не осилили. Сейчас надо сделать на 1С.

Внешние источники данных не осилили?

>>На текущий момент, при общем размере БД в 50 гигов, только этот регистр 14 гигов. В общем, печально все.

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


Марку в отдельный справочник можно выделить - но я не вижу никаких замеров по производительности. Возможно просто сделали подключение через ODBC и этот ODBC объект каждый раз создается да еще и в переборе строк каждый раз идет подзапрос.


Без кода не камлаю.
29 Kongo2019
 
16.10.19
16:19
(26) Так это уже регистр накопления получается.
30 Ёпрст
 
16.10.19
16:21
(29) итогов нет и..почитайте за разницу, что ле
31 tesseract
 
16.10.19
16:22
(29) Нет. Измерение по марке идет. Ключ перезапишеться - все данные перезапишуться.
32 Kongo2019
 
16.10.19
16:24
(28)
1. Нам скорости не хватило. У меня сервер хороший десктоп. Я уже за 500 гигов ушел. Но у меня ушедшая марке в архив сбрасывается. Активный объём 10 гигов.

2. Обслуживание базы сделал как 1с рекомендует.
Статистки раз в сутки, реиндексация раз в неделю.
33 Kongo2019
 
16.10.19
16:25
(30) Ну логика работы получается.
34 tesseract
 
16.10.19
16:28
(32) 1С ясно дрыщевый сервак, на котором Майнкрафт и bitcoin вертиться вдобавок.

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

Убери все индексы с регистра кроме измерения с допупорядочиванием.  Посмотри какие запросы идут к регистру - 95% код в проведении кривой или вообще в подписках какой-нибудь умник допроведение поставил.
35 Провинциальный 1сник
 
16.10.19
16:32
(32) Случайно у вас к регистру обращение производится не запросом с ПОДОБНО по измерению?
36 Kongo2019
 
16.10.19
16:36
Да хрен его знает. Это отраслевая конфа, я только засел ее ковырять. Она еще и с СЛК защитой.
И пилить мне ее точно не разрешат.
37 tesseract
 
16.10.19
16:42
(36) И сколько платят? СЛК всегда можно расковырять, если совсем код в dll не перенесли.
38 unregistered
 
16.10.19
17:50
Офигеть. Круто... Народ обсуждает методологию, не зная вообще ТЗ.
Как можно вообще о чем-то говорить, не зная ни для чего этот регистр, ни какие по нему строятся отчеты, ни какие данные, когда и куда берутся?
Может там надо десяток маленьких регистров делать причём разных - накопления (остатков и оборотов), сведений (обычные и периодические) и расчета (с периодами действия и без).

Без методологической постановки - это всё разговоры о сферических конях в вакууме.
Единственное более или менее разумное высказывание в (25): "...регистр нуждается в нормализации, слишком много ресурсов связаны с маркой. Есть смысл в декомпозиции на несколько регистров ...  и марка это справочник". Это то, что сразу бросается в глаза. Но более детально и подробно говорить нельзя без знания методологии и бизнес-процесса - для чего вообще всё это нужно.

Всё остальное - ересь, которая быть может на какое-то время что-то где-то локально улучшит автору в плане скорости. А через пару лет всё встанет колом.
39 tesseract
 
16.10.19
18:46
>>А через пару лет всё встанет колом.

Гораздо быстрее.

>>слишком много ресурсов связаны с маркой.

Если марка это GUID - никакого смысла делать отдельный справочник.
40 Kongo2019
 
17.10.19
13:35
(38) Ну есть какие общие-то практики проектирования.
Независимо от того, куда вы едете — это в гору и против ветра!