Доброго дня!

Имеется РИБ из УТ 11, достаточно немаленький. С центральной базой под 150 активных пользователей и овер 200 конечных узлов. Рост объема передаваемых данных и пользователей в центре привел к появлению каскадной схемы.
1. Центр;
2. 2 базы исключительно для обмена с конечными узлами;
3. 200+ конечных баз.

2 уровень сильно снял нагрузку с центрального узла, но сам постепенно начинает захлебываться. Увеличение числа баз этого уровня, конечно, решило бы проблему, но в силу обстоятельств это невозможно. Оптимизировать код в событиях при и перед записью, где наблюдается основной затык, (типа "Если Источник.ОбменДанными.Загрузка Тогда возврат" и тд и тп) возможно не во всех случаях. Да и логика должна быть разной для разных уровней, поддерживать ее затратно.
Было придумано опустошить конфу баз второго уровня от всего прикладного кода, оставив только стандартные подсистемы, а изменения конфы пускать напрямую из центра в конечные узлы через новый план обмена.
Проблему с рассинхронизацией конфигураций в каскаде думается решить так, как показано здесь во 2 методике http://infostart.ru/public/65456/

Вопросы: кто-нибудь работал с подменой хэшей? какие подводные камни возможны?

(0)В статье говорится об идентичных конфах, просто расинхронизированных. А у вас как я понял они будут отличатья даже на структуры. Имхается мне, что не взлетит у вас.

*на уровне структуры.

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

(3)Да например добавят новый реквизит хотябы в док в центре, а в переферии соответсвенно его не будет. Вот тут и загнется чтение сообщения.

РИБ с разными конфигурациями не взлетит

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

(6)А не проще сделать риб с правилами обмена?

(6)Если структура одинаковая - правила сделать секундное дело.

1)Использовать РИБ для синхронизации конфигураций без данных, уровень 1-3
2) данными меняться через план обмена без РИБ,уровни: 1-2, 2-3

А лучше всего поправить учет. Смысл все сливать в центральную базу? Сливайте свод, а для деталей можно уже и в базу спустится
\

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

(11) а если отключить РИБ, то правила обязательны?
Если структура одинакова, то наверное можно без правил.
Или я ошибаюсь?

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

Потом пакет идет в каждую базу в котором по 100 узлов? И при записи по организации регистрируются данные?

В чем все же выйгрыш по времени?

(12) Ошибаешся.

(13) выигрыш от каскадной схемы - работоспособность главного узла: 2 комплекта файловых операций вместо 200, 2 выборки/загрузки изменений вместо 200. Положительно для нагруженной базы. Избавление от блокировок.

выигрыш по времени для 2 ступени каскада я описал в (0)

>>Оптимизировать код в событиях при и перед записью, где наблюдается основной затык...

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

(0) возможно софтпоинт знает что с вами делать

http://softpoint.ru/products_id28.htm

(14) а зачем в БП2, например, в настройках обмена данными есть флажок "Обмен по правилам обмена"?

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

(15) Может проще по времени скапливать обмены в папке, потом обработкой их сжимать в один файл и грузить одним разом?

(20) + В итоге тоже самое и не надо городить огород с промежуточными базами

(18) без правил обмена работают риб. но риб может быть и по правилам обмена.

(20) так не дело, номера сообщений и прочее идут лесом, что неприемлимо

(23) Кто это сказал? 0_о

(24) + Вы просто не умеете их готовить.

(25) + Да и судя по реализации автора у них и так они идут лесом. Загрузка происходит в один миг сразу по половине узлов.

(26) у автора всё нормально, данная схема работоспособна.
(24) из 100 узлов в центр не выгрузились 2. Ты сжал 98 файлов, загрузил. С другими 2-мя чего делать? Какой ответ ты о загрузке 98-ми узлов пошлёшь и кому?

(27) Имеем те же 200 узлов, но загружаем одним пакетом.

(28) ещё раз. выгрузились не все 200 (причин более чем дохрена для такой ситуации)

(10) этот вариант мне больше всего нравится.

(29) Еще раз , загрузили те что выгрузились, по тем узлам что не выгрузились имеем старый номер пакета.

(31) нафига в 1 файл сливать тогда, я не понял, если у каждого узла всё равно своя нумерация сообщений

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

(33) + И все же я не понял в чем выйгрышь, так как размер данных не уменьшился, но если проще загружать данный одним махом, то предложенный вариант хорошо отсуствием промежуточных баз.

Тоже самое и по выгрузки, выгружаем без отбора по узлу и формируем файлики...

(33) автора мучает вопрос о "неработоспособности базы" при постоянной загрузке-выгрузке с 200 узлами,
его схема разгружает центр, консолидируя изменения в других узлах, номральная схема. Да, потом всё равно загружать надо тот же объём данных, но уже проще, всего 2 узла, проще контролировать.
Ещё автор хочет, чего я вобще не понимаю, конфу накатывать минуя промежуточные узлы, это вобще с концепцией РИБ не согласуется, и тормоза не в том месте ищет, ИМХО

(36)  Ну и прекрасно, загружаем одним пакетным образом изменения по сем узлам, которые успели положить в папку. И выгружаем разом по всем узлам.

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

(0) А вся это кухня это одна фирма? Одно юр лицо?
Либо (10) прислушаться. Или чаще делать обмен.

актуально

актуально