Капитальная архитектурная ошибка в регистрации изменений РИБ

Смотрите, как хранятся изменения в таблице изменений: Узел + Объект + Номер сообщения. Где номер сообщения - это номер пакета, в котором были выгружены изменения.

Но это КАПИТАЛЬНЫЙ АРХИТЕКТУРНЫЙ ПРОСЧЕТ. В результате операция выгрузки требует не только чтения таблицы, но и модификации таблицы. Т.е. при регистрации изменений происходит запись в таблицу изменений и при выгрузке происходит запись в таблицу изменений.

А ведь грамотнее было бы в Номер сообщения записывать номер последнего переданного в узел сообщения + 1. Тогда бы таблица изменений записывалась бы только при регистрации изменений, а выгрузка бы вообще не модифицировала таблицу регистрации изменений.

Я прав?

вообще проблема иногда возникает (у нас 60 баз, автообмены постоянные)

Для военных привожу пример.


Например, номер последнего отправленного сообщения на узел  - 10.

Записываем объект А, присваиваем номер 11.
Делаем выгрузку. Выгружается объект А-11.

Записываем объект Б, присваеваем номер 12. Номре сообщения - 12.
Делаем выгрузку. Выгружается А-11 и Б-12.

Записываем объект А в новой версии, номер не меняется, т.к. уже заполнен.
Делаем выгрузку. Выгружается А-11 и Б-12. Причем А выгружается в текущем состоянии из базы данных.

Теперь приходит загрузка.
Если пришло подтверждение пакета 11, то из регистрации изменений удаляетя А-11.
Если пришло подтверждение пакета 12, то из регистрации изменений удаляетя А-11 и Б-12.

Все, войла.

(12)(13) вот о том и речь, что типовой механизм реализован с просчетом... А менять типовой механизм, реализованный на уровне платформы на регистры сведений неэффективно... Как обычно, ребята с Селезневки лажанулись. Это радует.

при записи объекта в новой версии надо обновлять номер

(15) Гм, да, ты прав. надо.

Например, номер последнего отправленного сообщения на узел  - 10.

Записываем объект А, присваиваем номер 11.
Делаем выгрузку. Выгружается объект А-11.

Записываем объект Б, присваеваем номер 12. Номре сообщения - 12.
Делаем выгрузку. Выгружается А-11 и Б-12.

Записываем объект А в новой версии, номер меняется на 12.
Делаем выгрузку. Выгружается А-12 и Б-12. Причем А выгружается в текущем состоянии из базы данных.

Теперь приходит загрузка.
Если пришло подтверждение пакета 11, то из регистрации изменений удаляетя А-11. Но такого нет, значит А-12 остается.

Если пришло подтверждение пакета 12, то из регистрации изменений удаляетя А-12 и Б-12.

(17) напиши на селезневку, может в 8.3.3 добавят галочку в настройки плана обмена или еще как

шёл бы ты гений на партнерский с претензиями-то к 1С
там тебе быстро твои квадратные колёса куда-надо обратно вставят

(18) да, надо бы галочку сделать...
(19) квадратные колеса - это у них.

с регистрами как?

(19) не мысль здравая

(21) а ты смотрел, как таблица регистрации изменений для регистров выглядит? вот так и ручками ;)
хотя у меня (частично и из-за проблемы в (0)) подчиненные регистры без авторегистрации и выгружаются вместе с документами.

*не,

(22) вот-вот, ладно, запилю на партнерский, посмотрим, какой бледный вид будут иметь товарищи.

(21) что как с регистрами?
Когда я работал в одной конторе, откуда меня уволили, помню, мой босс сказал мне - предложи мне схемы обмена между складом и офисом. Я предложил на основе РИБ. Он сказал - нет, так не годится, предложи другие. Тогда я его не понял. Сейчас, когда поработал на реально больших обменах РИБ, понимаю, что у РИБ есть много косяков. Это и множественная передача одного и того же объекта и вот такая косячная схема регистрации.

(22) У меня вечер, поэтому подтупливаю. Объясните, мне, какая разница: если А выгрузили в 11 и изменили Оно зарегистрируется как А12 (так надо, чтобы отлавливать какие изменения удалять, когда придет подтвреждение загрузки 11)
Чем сие отличается от того, как сейчас - регистрируется выгрузка 10, при выгрузе и повторном изменении зарегистрируется как 11?
Ведь "КАПИТАЛЬНЫЙ АРХИТЕКТУРНЫЙ ПРОСЧЕТ" - это "операция выгрузки требует не только чтения таблицы, но и модификации таблицы"

(25) разница в количестве операций записи. Моя схема ровно в 2 раза меньше раз пишет в базу.

(26) И? А если кто-то шаловливыми руками изменил номер последнего отправленого сообщения на N+2 и при следующей выгрузке попытаются выгрузить не 13, а 14 - мы теряем то, что еще не выгружалось. Понятно, что оно при следующем цикле выгрузке уйдет, но ты уже не отловишь то что ранее выгружалось от того, что не выгружалось. Сейчас, емнип, пишется с пустым номером и ты можешь посмотреть, что эти были выгружены, а эти еще нет.

(27) сделай 100 узлов РИБ, покури, как оно будет работать

галочка нужна

или запилить хранимку на изменение номера отправленного

(27) В системах из 100 РИБ обычно за такое случайно бьют больно. Не нужно строить системы из расчета на дурака, надо строить из расчета на эффективное использование.

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

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

(29) Возможно нужна. Я не работал с РИБ-ами под 100 узлов (и слава Богу). Я не согласен с тем, что это имено используемая формулировка - на мой взгляд есть причина такой логики и она достаточно весомая.

(33) так озвучьте причину. У меня не 100 узлов, а 40, но выгрузка идет долго, по 5 минут на узел. А могла бы идти параллельно, если бы не ГЛОБАЛЬНЫЙ АРХИТЕКТУРНЫЙ ПРОСЧЕТ селезневских

(34) идти она может параллельно. а вот работать в базе - мешает.

(34) Профанация. Выгрузку можно заставить идти параллельно, это факт. Насчет двойной записи и т.п. - не туда смотришь, основные затраты идут на преобразование в XML и обратно. Также из минусов мешают блокировки потому как сделано похоже на merge репликацию(если знаешь о чем я). Кроме того нет гарантиии транзакционной целостности.(могут прийти и примениться половина данных транзакции, а остальные потом)

(0) ИМХО, овчинка выделки не стоит. При выгрузке обновляются только не выгруженные ранее записи. Сабж вроде как оптимизирует этот момент, но добавляет свои тонкости.
А оптимизируемый момент, ИМХО, далеко не является узким местом при выгрузке.

Всё нормально в типовом, нехрен. при выгрузке уже выгруженного но не принятого "там" элемента - номер не меняется,
наличие номера говорит о том что уже выгружено,
Учитывая тот факт что при выгрузке-загрузке таблицы изменений блокируются всё равно - пусть пишет при выгрузке номер, не жалко

(34) просчет вижу тока в том, что блокируются таблицы изменений целиком, что мешает паралельной выгрузке например, как и загрузке

(39) При правильной реализации не мешает. Если данные не пересекаются.

(38) Они блокируются не "все равно", а "потому что". Потому что идет двойная запись...
(36) меня интересуют не затраты времени, а параллельность, которая не идет из-за блокировок

(40) ну ка расскажи о правильной реализации, пока что это неаргументированно

Где то статья на сайте нашем была, лень искать.

(36) факт теоретический или практический, поделитесь опытом.
Пока что на ИС задачку решить никто не может:
http://forum.infostart.ru/forum14/topic71605/message817370/#message817370

(43) Слив засчитан, вернемся к аргументированной дискуссии

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

(39) вообще блокировка запией при выгрузке - это гуд, выгрузка должна быть защищена от грязного чтения!

по САБЖУ
есть минус - уменьшение скорости
есть плюс - мы знаем что именно выгрузили в пакете ХХХ,

что на самом деле важно!
пример:

запись обьекта
пакет 1 - выгрузили обьект
изменение обьекта
пакет 2 - выгрузка обьекта
получение подтверждени по пакету 1, пишем что данные получены...
пакет 3 - нет данных

в результате на перефирийке ПРЕДПОСЛЕДНЯЯ ВЕРСИЯ обьекта

http://softpoint.ru/article_id4222.htm
Покупай продукт и будет тебе счастье. Либо консалтинг. Оплата по результату при наличии договора. Я говорю то что видел и изучал. Но расписывать и доказывать ничего не собираюсь. По крайней мере без настроения.

У 1С много архитектурных недостатков но не нужно приписывать того чего нет на самом деле.

(47) Там другая проблема. Нет понятия единой очереди и факта фиксации транзакций. Поэтому может быть такая ситуация когда приходят движения табличной части документа и шапки а движений регистров еще нет.

(47) Где так? В 8-ке
пакет 1 - выгрузили обьект
изменение обьекта = запись с новым номером сообщения
пакет 2 - выгрузка обьекта
получение подтверждени по пакету 1, пишем что данные получены, но номер сообщения меньще пакета 2, поэтому данные по изменению объекта не удаляются
пакет 3 - выгружаем объект

(46) Если проанализировать куда уходит время при обмене, время на запись на уровне TSQL уходит ничтожно мало. Так что хоть трижды писалось бы это не было существенным.

(52) почему падать на блокировках при выгрузке может?

+(52) К тому же ты путаешь двойную запись всего объекта и простой апдейт(или инсерт) ссылки на измененный эллемент. Эта операция просто ничтожна настолько что бы ее обсуждать.

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

(53) Это несколько другая проблема. Время записи ничтожно а вот то что блокировка все это время держится - это другой вопрос.

(56) ну так в том-то и дело. нет апдейта - нет блокировки.

(41) блокируется именно "всё равно", при Чтении таблиц изменений они блокируются тоже

(48) гыгыгыгы... ловко пропихнул рекламку. Мне не нужен продукт, мне нужен принцип. Или возможно принципиально, или нет.
Мы тут теорию обсуждаем, не нужно сюда бабки приписывать. Засчитал слив

(55) Практически это возможно. Если бы не было проблемы блокировок то вероятность этого была бы ничтожна. Но так как блокировки при обмене присутсвуют то эта проблема становится более чем реальной.Вероятность зависит прямо пропорционально от времени захвата всех таблиц выгрузки. Если нет ожидания на блокировках это практически мгновенно. Если же есть то время может существенно(в 1000-и раз) увеличиться и следовательно вероятность.

(51) +1, именно

(59) Я тебе точно говорю что возможно. Но на слабо меня не возьмешь;)

(61) нет, в (51) неправильно написано. другое дело, что при регистрации-перерегистрации при подходе (0) удет постоянно дергаться узел на предмет последнего номера (или номера сообщения, который сейчас выгружается)

(58) + таблицы изменений не блокируются по записям, они целиком

(63) в (51) поведение при ситуации (47), в переферийке в итоге будет последняя запись, а не предпоследняя

(65) читай (17)

В 51 описывал существующий механизм. Если в 47 имелось ввиду предложение топикстартера, не в тему. 17 тоже не в тему, т.к. оно именно предложение

(66) читал, не вижу отличий от текущей ситуации с обменами, так и есть. При изменении выгруженного объекта - номер сообщения очищается, и при след выгрузке присваивается ему больший номер

херня

всё херня, новый год скоро

читать ЖКК до посинения. там с картинками

(68) в (17) и в (0) номер сообщения меняется в момент регистрации, а не при выгрузке

Номер сообщения меняется при вызове метода Выбрать() и при записи в основную таблицу.

(73) Пардон при вызове метода ВЫбратьИзменения()

(72) в (17) он так ХОЧЕТ) щас при выгрузке, я к тому что пусть срёт в одну руку, а хочет в другую - потом посмотрит какая первей заполнится :)
Гений утверждает что из-за присвоения номера сообщению при выгрузке возникает блокировка, но блокировка не из-за этого же

(75) проблемы две
1. Лишняя операция записи.
2. Как следствие, лишняя блокировка

(76) да даже при чтении таблицы изменений блокируются щас, какая лишняя? она одна большая

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

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

(79) Я разговариваю об оптимизации. Понятно, что в этом вопросе есть те, кого и Жигули устраивают. Но хочется Мерса

(80) ну, там не такая разница будет. как между 2106 и калиной примерно.

(0) капитальный архитектурный просчет - это ты, а номер сообщения правильно там хранится. Ты просто читать не умеешь. Это именно "это номер пакета, в котором были выгружены изменения", а не "номер, следующий за последним выгруженным на момент регистрации"

(76),(78) Ну что же - тогда удачи:)
P.s. При двойном изменении одной и той же записи(из одной и той же сессии) количество блокировок не увеличивается.

(82) Я предлагаю изменить схему, а не анализировать существующую, давай без буквоедства.
(83) В текущей схеме запись идет при регистрации изменений и при выгрузке. В моей схеме только при регистрации изменений. Эти события разнесены по времени.
(81) но зато можно запускать параллельно без гимора.

(84) в текущей схеме запись идет, если не пусто, в твоей - если не макс номер. в чем разница?

(0) Риб  гонять .... это дешево и сердито :)

риб ради загона рибом....

(85) если не пусто - всегда. проставляется номер сообщения.

Вот чуствую. что есть подлость, но только вот где она...

Кажется мне, что Гений забыл про мелочь: регистрация изменений и выгрузка данных всё-таки различные сущности, это ассинхронные события и они имеют время исполнения - что важно при многопользовательском режиме работы.

"номер последнего переданного в узел сообщения + 1" - это как-то, знаешь ли, абстрактно во время формирования сообщения обмена :)

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

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

Гений, не тупи :) "Нужный номер" - это какой?

Ок, допустим, выгружаем сообщение номер "12". Какой номер у новой регистрации изменения?

Номер "12"? Не факт, что изменение войдет в сообщение обмена.
Номер "13"? Не факт, что сообщение обмена будет сформированно...
С сообщением обмена всё ясно - откат транзакции и никаких следов, а у тебя в базе регистрация изменений с номерами "12" и "13"... приплыли :(

(88) "всегда" надо заменить на "при выгрузке всегда"

(92) я о выгрузке и балакаю. Не буквоедь.
(91) Если ты хочешь, чтобы при очередной выгрузке изменения ушли в центр, ты ставишь по классической схеме. То бишь, если у тебя номер последнего переданного сообщения - 10, ты ставишь при регистрации номер сообщения 11. Не вижу проблем.

Работал с 8.1 с РИБ из 180 узлов (точнее сам писал хитрый обмен где доки мигрируют по условиям в их реквизитах) и могу сказать что РИБ в 8-ке идеален если сравнивать с УРБД в 7.7!

(94) идеален - это когда нет вопросов, а вопросы у меня есть в сабже. Хороший РИБ, не спорю, но не идеален

Отправил селезням:
http://partners.v8.1c.ru/forum/thread.jsp?id=1104204#1104204

Гений зассал на партнерском написать "капитальная архитектурная ошибка".
Скромно так выступил, в предложениях: "Просьба добавить".
бгг

(93) "Не вижу проблем" - подробно распиши ситуацию "Регистрация изменений во время формирования сообщений обмена" - и ты увидишь.

Какой номер присваивается новой регистрации изменений во время формирования сообщения обмена?
Когда изменяется "номер последнего переданного сообщения"?
В начале или в конце процесса формирования сообщения обмена?
Какие номера будут у "старых" и "новых" регистраций изменений после отмены трнзакции выгрузки сообщения обмена?

(98) я в примере подробно это привел. как на партнерском, так и тут, курите (17)

(100) остатыщ

(97) вдруг у них разовьется комплекс неполноценности?

(84) да нет ни какого буквоедства, просто ты неправлиьно понимаешь ту чущность, которая перезаписывается при выгрузке. Это сетчик, котрый считает, сколько раз вот это вот было выгружено по сути. Если этот счетчик не сохранять, потом ты хрен узнаешь, когда и какие изменения были и не были получены.
Ты предлагаешь не исправить, а поломать

(102) я предлагаю все правильно. Номера сообщений сейчас это просто счетчик, из-за этого в два раза больше записей делается. Я предлагаю изменить схему и задействовать счетчик.

Лефмихалыч, я с трудом удерживаюсь от фразы "не тупи". Хватит мыслить стереотипно.

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

если выгружать по метаданным - то параллельность и при текущей схеме резко возрастает.

(105) дык вопрос про "следить и писать при регистрации" и как это соотносится с мерами по повышению параллельности работы живых пользователей

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

Например сделали копию базы, в которой был узел с номером отправленного 5, отключили обмены. Поработали в ней (изменили ряд объектов БД, по которым зарегистрировались изменения с номером сообщения 5). Потом перед включением обмена решили проверить узлы и обнаружили номер 5. Решили исправить его на 0. Запустили обмен. При этом имеющиеся изменения не будут выгружены, т.к. 5>1. А в текущей реализации такой сценарий приведет к выгрузке накопленных изменений. Разницы не будет лишь в случае, если сначала выгрузят сообщение, а потом исправят номер отправленного на меньший.

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

(99) Твоё (17) работает только когда поочередно идет регистрация и выгрузке. Такого можно добиться только при выгрузке в монопольном режиме. В реальной базе эти процессы, как правило, происходят ассинхронно и не всегда удачно.

Резюме: процесс регистрации во время процесса выгрузки ты не учитываешь. Вероятно - игнорируешь так, как она не укладывается в твою искуственную, надуманную схему.

Балаболка ты мелко плавающая, будь мужиком - докажи обратное :)

(107) Во время выгрузки можно проверять номер сообщения и редактировать при необходимости - вот такое решение вопроса - "и нашим и вашим" так :)

А вообще-то, всё сводится к банальному: есть факт выгрузки данных и этот факт нужно регистрировать. Так или иначе.

(0) по факту это решение точно встрянет на блокировках и увеличению чтению в транзакции (в момент записи) из базы, что намного хуже чем текущее решение.

(44) Решение есть и оно позволяет достичь параллельности в работе. Более того можно нормально выгружать данные по нескольким узлам и одновременно работать.

(103) это такие мелочи по сравнению с другими моментами, которые происходят в момент обмена данными типовым средствами для РИБа.