Вход | Регистрация


1С:Предприятие :: 1С:Предприятие 8 общая

Вопрос быстродействия: таблица регистрации плана vs регистр сведений?

Вопрос быстродействия: таблица регистрации плана vs регистр сведений?
Я
   Gorr
 
30.07.18 - 09:38
Как известно, планы обмена заточены под работу через БСП и с количеством узлов обмена более 2х. В случае если в интегрируемой конфигурации всего два узла и нет БСП, мне видится более оптимальным решение задачи регистрации ссылочных объектов к обмену через независимый непериодический регистр сведений.
Интересно мнение экспертов в области быстродействия.
 
 
   Cyberhawk
 
1 - 30.07.18 - 09:41
При чтении кандидатов к выгрузке из регистра будешь его блокировать?
   Serg_1960
 
2 - 30.07.18 - 09:45
Первое: Планы обмена работали уже тогда, когда ещё не было БСП - что принципиального изменилось сейчас? Ссылка на БСП тут совсем "не при делах".

Второе: планы обмена работали уже тогда, когда их ещё не было в типовых конфигурациях :) Парадокс? Отнюдь нет. План обмена - это механизм платформы. Хочешь программно(!) работать быстрее платформы? :))
   Gorr
 
3 - 30.07.18 - 09:49
(1) Для операции чтения наложение исключительной блокировки не требуется
(2) В БСП это тоже осуществляется программно в соответствующих обработчиках "ПередЗаписью". К тому же при этом используются ПРО, а это накладные расходы. Я же все проверки о необходимости такой регистрации планирую реализовать в коде в тех же обработчиках.
   Gorr
 
4 - 30.07.18 - 09:51
+Если бы не думал, что регистры сведений реально легче, не было бы и темы.
   hhhh
 
5 - 30.07.18 - 09:51
(3) ну и чем тогда регистр лучше? делай то же самое через план обмена и будет тебе счастье.
   Serg_1960
 
6 - 30.07.18 - 09:54
(3) и (4) Это всё равно не объясняет желание использовать независимый непериодический регистр сведений. Таблицы регистрации быстрее - они пишутся одновременно с объектом а не отдельно от него (как в случае с РС).

(офф) Имхо, удивительно, как платформа может быстро лопатить данные, когда ей не мешает конфигурация :)
   Cyberhawk
 
7 - 30.07.18 - 09:54
(3) Ну ладно тебе, не придирайся :) При завершении чтения-выгрузки (для обновления признака, что объекты БД выгружены) будешь блокировать регистр?
   Gorr
 
8 - 30.07.18 - 09:54
(2) в случае с авторегистрацией быть может вы и правы, но авторегистрация не катит.
(5) подход делать так потому что так делают все и давно?)))
   Gorr
 
9 - 30.07.18 - 09:57
(7) все просто. при завершении выгрузки регистр будет очищаться. для конкретной задачи этого достаточно.
   Gorr
 
10 - 30.07.18 - 09:58
(7)+ а чем страшна эта блокировка в нерабочее время?
 
 Рекламное место пустует
   hhhh
 
11 - 30.07.18 - 09:59
(8) ну просто через регистр вообще это еще надо ведь писать. Это например 10000 строк кода тебе нужно самому написать. Там сотни разных нюансов, которые тебе сейчас не видны, но с которыми ты тут же столкнешься, как только начнешь. А через планы обмена всё давно написано.
   Serg_1960
 
12 - 30.07.18 - 10:02
(9) Я говорил хоть слово про авторегистрацию? Я хотел лишь напомнить, что таблица регистрации - это таблица самого объекта. Такая же как реквизиты и табличные части самого объекта. Принцип работы платформы с регистрацией изменений другой, ок?
   Gorr
 
13 - 30.07.18 - 10:03
(11) Без БСП писать по любому. Остается только вопрос что быстрее, а работа с регистрами сведений мне намного привычнее.
   guitar_player
 
14 - 30.07.18 - 10:05
(0) быстрее всего пишется регистрации на узлах в планах обемена, при записи нет контроля уникальности значений
   hhhh
 
15 - 30.07.18 - 10:06
(13) Ну ладно, просто если насчет быстродействия, то через регистр понятно на порядок медленнее будет. Ну и дополнительные проблемы возникнут, из-за разных нештатных ситуаций, которые у тебя не будут проработаны.
   cons24
 
16 - 30.07.18 - 10:09
(13) спалился
   Serg_1960
 
17 - 30.07.18 - 10:12
"Интересно мнение экспертов в области быстродействия"
PS.
"планы обмена заточены под работу через БСП" - нет, это заблуждение.
"с количеством узлов обмена более 2х" - нет, это тоже спорное утверждение.

"мне видится более оптимальным решение задачи" - без комментариев. Sorry, но доказательств обратного - не будет. Вы хотели услышать мнение - своё мнение я озвучил.
   Gorr
 
18 - 30.07.18 - 10:12
(12) С авторегистрацией операция может выполнятся в месте с записью, без для этого используется обработчик, а это исполнение кода 1с. Как это может быть одновременно?
   Gorr
 
19 - 30.07.18 - 10:20
(17) утверждение выше следует понимать как БСП используется для упрощения работы с планами и оправдывает использование последних в решении. Без БСП не вижу большого смысла в использовании планов.
По узлам - наличие узлов усложняют работу по регистрации/очистке. не боле.
   Галахад
 
20 - 30.07.18 - 10:23
(0) Гм. Оба исходных данные не верны. О чем можно спорить?
   Cyberhawk
 
21 - 30.07.18 - 10:23
(9) Так у тебя обмен односторонний, выходит, и без гарантии доставки. Еще и в нерабочее время? Тогда через планы обмена сам бог велел
   Gorr
 
22 - 30.07.18 - 10:25
(20) я не хочу спорить. хочу аргументы.
(21) Односторонний. Вы религиозный человек?
   Cyberhawk
 
23 - 30.07.18 - 10:25
"Без БСП не вижу большого смысла в использовании планов"// Большой смысл в накоплении (регистрации) изменений. И не нужно писать код.

"наличие узлов усложняют работу по регистрации/очистке. не боле"// См. (16)
   hhhh
 
24 - 30.07.18 - 10:28
(22) зачем тебе аргументы. Раз решил через регистры, делай.
   Gorr
 
25 - 30.07.18 - 10:28
(23) запись в рс это пара тройка строк кода.
а что смотреть в (16)?
   Serg_1960
 
26 - 30.07.18 - 10:30
(22) Да, Вы правы. Он ошибся с термином.
Не "односторонний" - а "неполноценный и неработоспособный" :))

Что будет в случаи неполучения сообщения обмена по какой-то причине? Регистрация Вами очищена. Нужен механизм подтверждения получения и успешной обработки в узле-приёмнике.
   hhhh
 
27 - 30.07.18 - 10:32
(25) удаление документа как будешь отмечать в своем регистре?
   Gorr
 
28 - 30.07.18 - 10:32
(26) А вот что будет: комулятивный апдейт периодически - это раз. удаление регистрации при получении сообщения об отработке загрузки по крайней мере без ошибок - это два.
   Gorr
 
29 - 30.07.18 - 10:34
(27) такая задача не стоит.
   Serg_1960
 
30 - 30.07.18 - 10:36
(28) "А вот что будет... раз... два..." - давай сразу "три" и закончим об этом: "я пишу свой альтернативный велосипед вместо внутриплатформенного механизма плана обмена".
   hhhh
 
31 - 30.07.18 - 10:38
(29) ну встанет, и будешь что тогда со своим быдлокодом делать?
   Остап Сулейманович
 
32 - 30.07.18 - 10:40
(26) А может ему не нужен "механизм подтверждения получения и успешной обработки в узле-приёмнике"? Ну например. Вполгн достаточно одностороннего обмена.

Вот в семерке не было планов обмена. И служба регистрации была достаточно примитивной. Не позволяла в коде фильтровать получателей. Пришлось пилить свою. На справочнике. Если на "той стороне" чего не получали (квитирования не было) - звонили менеджеру в центр и он добавлял нужное к отправке.

ЗЫ. Но более удобный вариант чем использование планов обмена у ТС вряд ли получится. Вся аргументация в (13) " работа с регистрами сведений мне намного привычнее." - попытка оправдать свою некомпетентность. Вместо того, что бы изучить работу с планами обмена.
   Cyberhawk
 
33 - 30.07.18 - 10:54
(32) Прикладным кодом (на регистрах и версиях объектов) можно сделать механизм обмена, который не будет иметь узких мест планов обмена. Но хайлоад - это конечно же не случай ТС.
 
 
   Gorr
 
34 - 30.07.18 - 10:57
Полемикой можно заниматься сколь угодно бесконечно.
Решение задачи в общем виде не всегда целесообразно (квитирование, множество узлов, удалениеобъекта). Задачу можно и нужно упрощать.
РС простейшая сущность стало быть и работать должен быстрее.
Более того, у меня есть подозрение, что включение регистрации объектов в планах скорее всего еще и будет тормозить саму запись этих объектов...
Для ответа на вопрос нужен замер производительности.
Утверждать обратное как минимум не дальновидно.
   Serg_1960
 
35 - 30.07.18 - 10:59
Я, наверное, оставлю без ответа вопросы в (32) и утверждения в (34). Иначе мы договоримся до того, что автор сознательно отказывается и нарушает основные принципы поддержания целостности и взаимной непротиворечивости данных информационной базы.
   Остап Сулейманович
 
36 - 30.07.18 - 11:04
(35) А я еще раз спрошу.)))
Ну вот если я делаю выгрузку на сайт. Допустим. И не владею методами работы с планами обмена. Допустим. Что мне выбрать?

ЗЫ. Лично я бы выбрал планы обмена. Потому что на них шишек набил уже не одну. Но если ТС не умеет их готовить - РС вполне себе подходящий инструмент.

ЗЫЗЫ. За поддержание "целостности и тем более непротиворечивости" в случае обмена с сайтом или любой другой посторонней БД речь скорее всего не идет.
   Serg_1960
 
37 - 30.07.18 - 11:12
(36) Насколько я понял тему автора - речь не об обмене с сайтом.

Я понимаю на что Вы намекаете :) Мол, при работе с сайтом "не всё так однозначно"(цы).

А теперь представьте сайт на котором можно оформить и оплатить заказ покупателя... :) Покупатель оплатил заказ и имеет право требовать его исполнения со всеми вытекающими из этого. Вот теперь ещё раз мне скажите, что пр обмене с сайтом "не принципиально" всё выше сказанное в теме :))
   Вафель
 
38 - 30.07.18 - 11:14
Использование планов обмена не заставляет использовать сообщения обмена.
а весь косяк именно в соощениях
   Serg_1960
 
39 - 30.07.18 - 11:18
Согласен. При постоянном и надёжном онлайне можно читать регистрацию базы-источника непосредственно в базе-приёмнике и импортировать нужные данные. При оффлайне этосложнее организовать :)
   Serg_1960
 
40 - 30.07.18 - 11:24
(38) "весь косяк" планов обменов в том, что между сеансами обмена базы работают автономно друг от друга. Вот где проблема так проблема :(
   Вафель
 
41 - 30.07.18 - 11:27
(40) и что? пусть работают
   Serg_1960
 
42 - 30.07.18 - 11:38
(41) Sorry, Ваш вопрос я оставлю без ответа. Это всё "Флейм и оффтопик" и к теме автора (напомню: который хочет отказаться от регистрации изменений в пользу РС) не относится.
   Aleksey
 
43 - 30.07.18 - 11:38
Вообщето в высоконагруженных системах как раз и отказываются от типовой таблицы изменений в пользу РС. А причина банальная. У таблицы изменений нельзя наложить управляемую блокировку.

На моей практики в типовой БП при включения стандартного плана обмена при закрытии квартала и групповом перепроведении параллельно разными бухами по разным организациям наблюдаются блокировки и чем дольше небыло обмена (чем больше данных в таблице изменений), тем блокировки чаще. (P.S> последний раз правда это было на платформе 8.2, как на 8.3 не знаю, ибо с переходом на БП 3.0 отказался от УРИБ и планов обменов в пользу единой базы).

По сути таблица изменений для каждого объекта одна общая и блокируется полностью, а вот конкуренция на запись туда не маленькая. Это и сами пользователи и обмены (при отправки туда пишется номер пакета, а при записи чистятся полученные)
Т.е.
   Aleksey
 
44 - 30.07.18 - 11:41
Вообще немного по теме можно глянуть тут https://forum.infostart.ru/forum15/topic185103/
   Serg_1960
 
45 - 30.07.18 - 12:00
(43) Я полностью согласен с Вами относительно высоконагруженных систем. Но автор об этом ничего не сообщал.
(44) Я бы ещё порекомендовал, например, http://expert.chistov.pro/public/561460/

Хочу уточнить: я не против, если автор желает полностью отказать от использования плана обмена в определенном конкретном случае. Да, при определенных условиях (и если автор совершенно уверен, что они не изменятся со временем) в частном случае можно отдать предпочтение РС как альтернативе. Ему виднее.

Я только хотел напомнить об том, что тогда придется полностью "эмулировать" саму методологию работы планов обменов.
   Cyberhawk
 
46 - 30.07.18 - 12:02
(45) Зачем ты ссылку на ИС заменил на чистовскую?
   Aleksey
 
47 - 30.07.18 - 12:09
(46) Это к ВР инфостарта. Расплодил клонов....

Просто в яндексе ввел строку поиска и неглядя дал первую ссылку из яндекса
   xxTANATORxx
 
48 - 30.07.18 - 12:13
(0)всё не читал,
используйте план обмена, а там как вам больше нравится через БСП или как-то иначе, это дело вкуса
   Gorr
 
49 - 30.07.18 - 12:14
(43) Благодарю за развернутый ответ по существу, да еще и со ссылками!!!

(2) А Вы быстро свое мнение меняете)
 
 Рекламное место пустует
   Serg_1960
 
50 - 30.07.18 - 12:15
(46) Во первых, я не "заменил", а "дополнил" - я сказал "ещё" :) Во-вторых: в ссылке Инфостарта тема начинается от "как всем известно"(цы). Я не раз убеждался что многим это, увы, не известно. В ссылке на Чистова рассмотрена сама структура таблиц регистрации изменений и работа платформы с ними.
   Serg_1960
 
51 - 30.07.18 - 12:21
(49) Я не меняю своё мнение, я остаюсь при нём. Я предлагаю Вам флаг в руки, барабанные палочки и вперед по шпалам навстречу электричке :))

А если без шуток, то почему Вам действительно не попытаться самом реализовать "более оптимальное решение задачи"? Я предупредил, Вы - услышали. Моя задача выполнена.
   Serg_1960
 
52 - 30.07.18 - 12:44
»
   Cyberhawk
 
53 - 30.07.18 - 14:08
»
   Serg_1960
 
54 - 30.07.18 - 15:39
»
   Cyberhawk
 
57 - 30.07.18 - 16:21
»
   Serg_1960
 
58 - 30.07.18 - 16:26
»


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