Количество записей в планах обмена все растет и растет. Решил как-то разобраться. А может попробовать ручную регистрацию изменений. Может скорость обменов увеличится в десятки раз? Как ускорить обмены?
Итак. Долой всю справочную литературу со всеми помощниками…

Итак сравнение (на примере справочника или документа):
Авторегистрация. Кратко об этапах:
1) Регистрация ВСЕХ изменений (автоматическая естественно)
2) При обмене выборка этих самых зарегистрированных изменений (очень долго – 45% времени)
3) Функция проверки а нужно ли перегружать данные, если не нужно то выгружаем УдалениеОбъекта (долго)

Ручная регистрация.
1) Регистрация ВСЕХ изменений (ручками) при этом проверяются на нужные или не нужные все объекты (долго). Ненужные ведь тоже надо регистрировать как УдалениеОбъекта, иначе могут остаться скорректированные данные (часто бывает такое), т.е. в основной базе данные будут изменены, а в получателе навсегда останутся старые, которых вообще не должно быть.
2) При обмене выборка этих самых зарегистрированных изменений (очень долго)

Как ни крути везде одинаково долго. Что делать? Как ускорить обмены?

код в студию...
Не верю, что ДОЛГО. Если, конечно, обмены делаются не раз в год

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

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

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

(1) не раз в год
(2) не нужные тоже ведь должны попадать как УдалениеОбъекта
часто бывает такое, что заказ приняли на одного клиента из Питера, и заказ по обменам улетел в Питер. Затем оказалось, что этот заказ не Питера а Москвы, тогда после его изменения, он улетает в Москву. Но, чтобы в Питере он УДАЛИЛСЯ НУЖНО ИМ ТОЖЕ СДЕЛАТЬ РЕГИСТРАЦИЮ УдалениеОбъекта.

Конфа самописная.

(3)
(4)
спасибо за бесполезные советы

(1) пока обсуждается алгоритм. Кода нет.

(5) Ну и?

Если у тебя сотня узлов, то имеет смысл вручную регистрировать

(8) записи типа удаление объектов как раз и выполняются долго. Особенно заметно, когда нужных 1% данных а остальное УдалениеОбъекта.

Может в идеале никакие данные не должны меняться ни задним числом ни вчерашним днем и даже часом, но у нас такое не реально.

(9) сотни пока нет. А в чем этот смысл? Где я получу преимущество? в каком месте?

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

(10) Удаляй данные ночью и обменивайся после этого.

(9) когда зазипуешь XML в котором нет двоичных данных, то это не проблема. Тексты зипуются на ура!

(12) когда зазипуешь XML в котором нет двоичных данных, то это не проблема. Тексты зипуются на ура!

(12) Если делать без УдалениеОбъекта, то да. Результаты ошеломительные. Производительность возрастает на 2 порядка. Но ненужные данные постепенно начнут искажать данные.

(15) Сразу видно - теоретик. Напишешь МП для КПК, поговорим)

(16) Читай (13).

"Ненужные ведь тоже надо регистрировать как УдалениеОбъекта, иначе могут остаться скорректированные данные (часто бывает такое), т.е. в основной базе данные будут изменены, а в получателе навсегда останутся старые, которых вообще не должно быть." - или бред, или бардак, что является следствием тормозов.

(17) на КПК размеры баз значительно меньше. Количество таблиц меньше. Количество данных попадающих в обмены меньше. Че тут говорить. Да и трафик сейчас не проблема.

(19) ну если бардак то не совсем. А в чем бред?

(20) Вот я и говорю, что тут говорить - "Пастернака не читал, но осуждаю"...

(21) бред в том, что если исходить из того, что всё правильно было изначально сделано, то в периферии не должно быть объектов, которых там не должно быть.

(22) Яйцами мерятся не на этом форуме. Я сюда пришел не спорить, а за помощью.

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

(24) А на каком?
По сабжу, ответ в (2), что ещё надобно?

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

Наверное, ты не внимательно читаешь
1) Я не говорил, что при обмене есть проверки в случае ручной регистрации.
2) нужные попадают. И не нужные тоже как УдалениеОбъекта читай (5)

(23) данные корректируются всегда. Читай (5)

(27) А я тебе ещё раз говорю, читай (13).

(28) ну тогда только чтение специальной литературы и собственный моск спасет отца русской демократии, Радченко, к примеру.

(29) (13) Что значит удалять? Удаление происходит в обменах. Удаление и обмены нельзя попилить пополам.

(0) Задача разгрузить сервер

(30) чтение форумов мне больше нравится :)

(33) нравитсо, когда какахами кидаются? мсье знает толк в извращениях))

(31) Ты понимаешь, что такое УдалениеОбъекта? Это значит, что какой-то объект (читай документ) удалили из базы. Удаляй ночью.

(32) оптимально написанная ручная регистрация решит твою задачу.

(0) может кто-то знает про какие-нибудь хитрые механизмы. Конечно, можно писать удалениеОбъекта только в некоторых случаях (когда есть изменения), но описывать все эти случаи довольно-таки сложно.

(36) вот мы и говорим об этом :)

(38) ну так и формулируй проблему достаточно полно, а то написал каких-то общих фраз в (0) и ждешь помощи как манны небесной

(35) хорошо понимаю. Это такой тип данных. Я его пишу в файл обмена XML, чтобы в узле получателе удалялись данные по ссылке, которая в них хранится.
Это не разделимые два процесса. К тому же ночью сервер тоже не спит.

(39) описал 2 алгоритма обмена данными как с авторегистрацией так и с ее запретом, причем кратко. Тот кто разбирается в обменах тот поймет. Если непонятно, то поясню, тока спрашивай что именно

(40) Чет я устал с тобой общаться... Читай (39), добавить нечего.

(40) ты проверил, после принятия ответа от периферийной базы у тебя всё очищается в таблицы регистрации, что должно очищаться?

(41) Если ты сам в обменах не разбираешься, то с чего ты взял, что "Тот кто разбирается в обменах тот поймет"?

(43) да. Все очищается.

(45) тогда совсем становится не понятным утверждение "Количество записей в планах обмена все растет и растет"

(46) в таблицах изменений записи не удаляются

(44) откуда такая уверенность? Я не говорю, что я гуру обменов. В общем разбираюсь как в типовых механизмах обмена данными, так и в своих самописных. Решил попробовать ручную регистрацию. Не увидел преимуществ. Вот и вопросы.
А что тебе то не понятно?

(46) а ну это потому что количество узлов все растет и растет.
(47) все удаляется

(48) да какие преимущества ты хотел увидеть кроме как ручного указания что регистрировать и каким узлам-получателям? тоже самое можно делать и при автоматическом путём удаления регистрации для ненужных узлов

(46)
(47)
делаем акцент на теме!

(6) Как раз это самые полезные советы.

(50) можно, но в таком случае полезут блокировки

(0) как часто происходит обмен?

(0) У кого-нибудь есть получше варианты чем то, что предложено (37)?

(54) в среднем раз в 30 минут с каждым узлом. Узлов 4 десятка

(56) на сколько за это время набивается план обмена?

(56) я веду к тому, что может быть уменьшить время между обменами?

(58) здесь тоже ведутся работы в сторону уменьшения интервала между обменами до 0 (со стороны главного узла это условие выполняется). Но хотелось бы снизить нагрузку на сервер. А также оптимизировать обмены, чтобы выполнялись так же быстро как в случае без РегистрацииУдаления объекта.

сейчас документы из подчинённого узла №6 летят в подчинённый узел №12? я полагаю что они все нужны только в центральной базе, в подчинённых только своё. Для уменьшения мигрирующей инфы надо регистрировать только для нужных узлов, что к удалению то привязались? Если при обменах только 1% норм инфы а остальное удаление - это бардак в базе и головах пользователей ИМХО

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

(60) Да. все верно. Регистрация для нужных узлов...
Есть опыт, что ненужно тоже надо удалять. Заранее неизвестно, есть в подчиненном узле или нет объекта. Скорее всего нет, но есть вероятность 0,0001%, что он там есть и попал из-за чьих-то корявых рук.

Получается проблема описанная в (5)

Выход пока в (37). По умолчанию не писать УдалениеОбъекта, а только в исключительных случаях писать. Например, когда поменялся клиент и т.п. Но это на первый взгляд не просто сделать, хотя если написать пару функций, то может все и получится.

(0) решено в (62)

(61) спасибо. я к этому же начал склоняться. Только это все должно происходить автоматически. Пусть будет решение в (62)

(62) как раз при изменении объекта можно понять, в какой узел нужно его отправить и в каком его нужно удалить. а если "Заранее неизвестно", то это бардак.

(64) и как ты поймешь в каком удалять?

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

(65) а по какому принципу посылалось только в один узел а не во все? по тому же и удалять

(66) интересная мысль. Сравнивать получателя старого и нового?

(67) если все подряд удалять то долго. Об этом и дискуссия.

(68) мысль очевидная, да, сравнивать

(70) в подписках "при записи" делаю регистрацию для нужных узлов.
в подписке "перед записью" если объект не новый, то сравниваю получателей старых и новых. Если в новых не найдено старых, то старым пишу УдалениеОбъекта.

Ну в общем то решение мне очень нравится.

(71) докрути к этому ручную регистрацию и будет оптимально

(72) я бы сказал наоборот докрутить ЭТО (71) к ручной регистрации и будет супер четка :)
Планируется прирост в скорости почти в 100 раз в теории ну и посмотрим, что получится на самом деле.

(73) да, отпишись о результатах)

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

(75) а что за зверь такой "автозаполнение"? При = Ложь Не будет регистрации изменений что ли?

(76) не будут автоматически заполняться узлы-получатели