Для чего нужен РИБ с двумя планами обмена: РИБ и НеРИБ ? #772937


#0 by vi0
Есть задача организации двухуровнего РИБа. Количество баз исчисляется сотнями, но количество документов, в принципе, небольшое. Вентилируя эту тему, иногда встречаю способ организации с двумя планами обмена: 1. РИБ для передачи только конфигурации 2. Не РИБ для обмена данными Коллеги, поделитесь, кто использует подобное? В каких случаях интересна подобная методика?
#0 by vi0
Есть задача организации двухуровнего РИБа. Количество баз исчисляется сотнями, но количество документов, в принципе, небольшое. Вентилируя эту тему, иногда встречаю способ организации с двумя планами обмена: 1. РИБ для передачи только конфигурации 2. Не РИБ для обмена данными Коллеги, поделитесь, кто использует подобное? В каких случаях интересна подобная методика?
#1 by Aleksey
не взлетит РИБ при количестве баз более 10 уже гемор, а уже когда их сотни... тут даже не вопрос риб не риб, а тут надо уже рассматривать вопрос ухода от звезды к дереву
#2 by vi0
все таки, предлагаю вопрос топика обсудить
#3 by vi0
а если есть твердая уверенность, что не влетит, то почему именно
#4 by Aleksey
Ограничения архитектуры 1С + скорость работы.
#5 by Defender aka LINN
Так а почему не почитать там, где ты это встречаешь?
#6 by vi0
это общие слова
#7 by Aleksey
По суди таблица изменений используемая в 1С одна на всю таблицу и не поддерживает гибкие блокировки. Как факт нет никакой возможности распаралелить процесс обмена. т.е. все обмен загрузка и выгрузка будет идти последовательно для каждой базы. Т.е. даже если исходить что на каждую базу будет уходить по 5 минут (а это минимум, тебе же надо скачать файлик распаковать, прочитать, записать изменения, прочитать изменения, выгрузить в фалик, запаковать, отправить на фтп), то это более 8 часов на весь цикл обмена. Т.е. считать что минимум 12 часов нужно чтобы прогнать обмен со всеми базами
#8 by vi0
ну вот к примеру комментарий 66, где человек от вопроса ушел
#9 by Aleksey
Поэтому и строят дерево, а не звезду Ггрубо говоря базы обедняются по какому нибудь признаку т.е. есть центральная база у которой 10 почек. Каждая почка имеет свои 10 почек, для которых она центральная
#10 by vi0
базы раскиданы по всей России, одновременного обмена не будет
#11 by Aleksey
А никто и не говорит про одновременны, просто центральная база у тебя будет с утра до вечера грузить обмен. И не дай бог переферейки решит перепровести квартал перед сдачей отчетности. Всю стопор минимум на пару недель тебе обеспечен, т.е. как минимум на 2 недели данные в центре будут не актуальны
#12 by vi0
> перепровести квартал перед сдачей отчетности такого не будет, базы оперативные, не для отчетности
#13 by Aleksey
Вы никогда не перепроводите оперативную базу?
#14 by vi0
в данном случае такой необходимости не будет
#15 by Aleksey
Что ты хочешь услышать? Исходя из своего опыта настройки типового обмена с 15 базами БП - считаю что не взлетит. Если ты считаешь иначе, то ради бога пробуй, только хотелось бы в будущем услышать твою историю успеха, какие грабли, как решал, чего добился. Любые другие советы ты все равно будешь воспринимать как "общие слова", но другого за бесплатно ты не услышишь. Настройка таких обменов (100+ баз) в типовой стоит денег, много денег
#16 by assasu
есть таблицы регистрации. есть регистры которые хранят объекты баз. все это при одном то узле  пухнет на гигабайты, а если будет сотня узлов все встанет колом. считаю что в типовом исполнении не полетит. надо пилить , обрезать лишнее напильником
#17 by vi0
спасибо за критику и проверку на прочность, но меня изначально другой вопрос
#18 by vi0
Коллеги, поделитесь опытом если вы использовали два плана обмена РИБ, НеРИб. Какие вопросы закрывали такой схемой?
#19 by assasu
расскажи что за базы у тебя и какие задачи решаешь. от этого зависит вариант .
#20 by Aleksey
Ну обычно не РИБ используется для случаев использование правил обмена.
#21 by vi0
интересуют вопросы оптимизации
#22 by assasu
делай все на КД, через правила.
#23 by Cyberhawk
"Коллеги, поделитесь, кто использует подобное?" Я "В каких случаях интересна подобная методика?" Вопрос неясен... "Интересна" в тех случаях, когда обмен нужен между конфигурациями, где хотя бы одна из них подвержена частому изменению. Например, между тестовой БД и рабочей БД для подкачки актуальных данных из рабочей в тестовую.
#24 by vi0
это ты рабочую базу так нагружаешь специальным планом обмена для тестовой?
#25 by AlexTim03
Все взлетает. Также используем в одном проекте такую схему. Есть Управление Торговлей 11.0 -фактически центральная база по данным. Есть куча РТ (Розничная торговля) - магазины. Соответственно обмен не РИБ - УТ-РТ - обмен данными (из РТ продажи, из УТ справочники - это если грубо). Но все РТ объеденены еще одним планом обмена - РИБовским. И есть центральная РИБ. Соответственно, все изменения конфигурации вносятся в центральный РИБ и раздаются на периферийные. Собственно, методика и интересна тем, что изменения конфигурации РТ идут отдельно (их не передать через УТ-РТ), а самих РТ много, чтобы заморачиваться какими-то другими механизмами и обновлять/проверять, что все РТ обновлены на нужную версию.
#26 by vi0
а центральная РТ без данных?
#27 by Cyberhawk
Естественно, а как еще подкачку сделать? Делается в периоды минимальной нагрузки
#28 by Фрэнки
А зачем в РИБ-центральной какие-то данные? там данные отключены практически полностью, за исключением заранее утвержденного перечня НСИ
#29 by Фрэнки
это можно даже как-то схематически описать. Причем, возможно и каскад построить, в котором несколько розниц района будут сливаться в районное оперативно, а затем уже заливаться в центральную статистическую. На районном масштабировании можно отработать и сводное нормирование заказов, когда формируются объемы поставок... В общем, вариантов можно много насобирать
#30 by AlexTim03
Да, центральная РТ без данных. Это техническая база, только изменения конфигурации.
#31 by Фрэнки
Самое интересное, что такое решение, когда создается заготовка для обменов данными из "пустых" начальных образов, можно без каких-то истерик накатывать по всем узлам торговой сети. Отрабатывается технологическая процедура для выгрузки загрузки данных (внутреннего стандарта) затем, когда существуют уже узел "единой конфигурации РИБ" - переливают в него накопленные данные текущей базы и дальше уже работают с нормализованном узле. Постепенно! Без обрушения работы всех узлов сразу, если "кто-то не на ту кнопочку нажал".
#32 by Фрэнки
Синхронизированную единую номенклатуру там можно вести :) При большом желании, конечно.
#33 by vi0
> Самое интересное, что такое решение можно другими словами - какую задачу решали?
#34 by Serg_1960
"иногда встречаю способ организации с двумя планами обмена" :) Типовая конфигурация УПП - 12 планов обмена :)) С розницей, с сайтами заказов и товарами, с конфигурациями УПП, торговли, документооборота; обычные и фоновые...
#35 by vi0
вы не на первом канале работаете случаем?)
#36 by Serg_1960
О_О
#37 by Cyberhawk
Он имеет в виду, что на каждый "канал обмена" (между парой баз) использовать не 1, а 2 плана обмена (один для передачи данных, другой - конфигурации)
#38 by Serg_1960
Только что зашёл на ветку. Ветка длинная, сижу читаю. Не удержался, бросил замечание. Планов может быть много, но это же не повод их все использовать одновременно.
#39 by Serg_1960
Это я понял. Не понял (ещё не дочитал) где автор такой совет прочитал и почему там объяснений не было дано такому странному совету :)
#40 by Фрэнки
в торговой сети я давно уже не работаю и тогда был не РИБ, а УРБД, но в последнее время риб-конфигурация + сверху план-обмена-данными - это есть. Причем, на одних и тех же базах крутится риб и два разных плана с разным составом объектов.
#41 by Serg_1960
Имхо: количество баз данных, как проблема в обмене данными, легко обходится созданием дерева обменов, причем это не исключает использование звезды на ветвях. Целесообразность использования второго плана обмена вижу (на вскидку) только в одном: когда в базе есть объекты, которыми нужно обмениваться значительно чаще, чем остальными. Исключаем такие объекты из "основного" РИБ-плана обмена и добавляем во второй план обмена. Тем самым снижаем градус проблемы периодичности "основного" РИБ-обмена. Вот как-то так на первый взгляд, особо не думая.
#42 by aleks_default
+1 ведь при изменении в структуре метаданных затрагивающих объекты, ходящие по второму (НеРИБ) плану обмена, все равно этот обмен остановится и будет дожидаться изменений конфы, приходящих по РИБ
#43 by Serg_1960
Упс :) ой, я вспомнил: я же сам однажды делал хитрый план обмена с двумя документами, когда между двумя филиалами (различными организациями) за счет плана обмена по правилам, реализация превращалась в поступление и наоборот. Тогда показалось забавным реализовать такое превращение в процессе миграции документов между базами. Не рекомендую :)
#44 by Serg_1960
Не совсем так. Как раз это его достоинство - изменение конфигурации такой обмен данными не останавливает. Естественно, если обновление не затрагивает объекты состава плана обмена.
#45 by aleks_default
а если внимательно прочитать что я написал
#46 by Serg_1960
Внимательно прочитал :) Ну да, ты прав, при некоторых изменениях обмен может падать/останавливаться. Всё зависит от изменений метаданных и того, как правила конвертации написаны.
#47 by Bober
да здесь я, здесь.
#48 by Bober
это реальная вещь и она взлетит.
#49 by AlexTim03
в том и дело, когда у тебя УТ - один центр, а РТ - 2000 магазинов, как реализовать 100% передачу и обновление конфигураций РТ с наименьшими доработками?
#50 by Tateossian
Взлетал РИБ на 200 базах.
#51 by Fragster
можно сделать на одном плане обмена, просто ручной выгрузкой и снятием с регистрации вместо стандартного механизма. а РИБ-часть с конфигурацией - по ночам.
#52 by Tateossian
Работало это так: сначала запускался скрипт, снимающий во всех базах главный узел, после этого заливалась конфигурация в каждую базу, потом ставился главный узел, после этого запускался обмен. А утром по логам смотрели ошибки. Но были они не часто.
#53 by Бубка Гоп
Звезда? Что за конфигурация? Интересно как в производительности новый вид обмена от 1с, через универсальный формат. Небось тормозит дичайше, пробовал кто нибудь?
#54 by Fragster
сотня-другая баз взлетает запросто - главное обеспечить "снежинку", чтобы напрямую подчиненных узлов было не больше десятка-двух.
#55 by Fragster
#56 by Tateossian
Две - самописка сметно-проектная и бухня, сначала 2.0, сейчас 3.0.
#57 by aleks_default
json который?
#58 by vi0
видимо, речь про 1С Конвертацию 3
#59 by vi0
> снимающий во всех базах главный узел это что именно?
#60 by vi0
двухуровневый РИБ?
#61 by Serg_1960
#62 by vi0
, а смысл тогда в РИБе?
#63 by Фрэнки
Только в запрете на внесение изменений, возможно. Хотя, постоянное отключение этого режима происходит, то в этом в самом деле смысла немного. У них, вероятней всего, направление обмена от периферии к центру. В этом случае, вместо обратной выгрузки РИБ с конфигом, передают конфиг отдельно. В общем, те же яйца - вид сбоку. Это когда в РИБ только конфиг, а все данные идут рядом.
#64 by Фрэнки
т.е. сверху вниз передается отдельно конфигурация, а снизу вверх только данные, которые принимает центр.
#65 by vi0
у РИБа передаются только изменения конфигурации, а там всю конфигу гонять не видны выгоды от схемы
#66 by Фрэнки
Надежность. Загрузка конфигурации произойдет всегда, даже если какие-то реквизиты или объекты для периферии сильно изменятся. Не приходилось наступать на грабли, что обмен по рИБ не проходит из-за каких-то не вполне объяснимых причин, точнее, из-за измененной конфигурации?
#67 by vi0
Какие именно причины?
#68 by Фрэнки
если программист не вполне аккуратно курочит объекты конфигурации, то тогда она (перекуроченная неудачным образом) через риб в узлы перифериек не проходит с классическим сообщением об ошибке: "Конфигурация узла не соответствует ожидаемой". И все приходится перезапускать по методе из
#69 by Лефмихалыч
сабж нужен как раз для двухуровневой структуры баз. При этом по "риб" логично не только конфу гонять, но и НСИ, общие для всей сети.
#70 by Serg_1960
"вырузить конфигурацию ЦБ / отвязать узел / загрузить конфигурацию в ПУ / привязать узел" - это общеизвестная альтернатива штатному обновлению конфигурации подчиненного узла. Иногда обновление конфигурации на ПУ глючит, сваливается по ошибке и тогда, кроме как альтернативы ничего из штатных возможностей платформы не помогает. Некоторые используют эту альтернативу для автоматизации массового обновления конфигураций многочисленных узлов в нерабочее время - батник на три строки и всего делов-то. Да и работает альтернатива быстрее штатного метода.
#71 by Serg_1960
Погугли, например, ошибку "Конфигурация узла распределенной ИБ не соответствует ожидаемой" или "демоническое обновление". Иногда бывает так, что загрузка конфигурации - единственный способ решить проблему.
#72 by vi0
а по второму плану обмена?
#73 by Фрэнки
а что по второму? НСИ идут от центра на периферию по РИБ, а оперативные данные, которые массово идут от периферии к центру - по плане НЕриб (как он там у тебя в топике назван :) )
#74 by vi0
и для чего тогда два плана?
#75 by Фрэнки
например, мне? в том варианте, с которым я работал недавно? или у тебя в твоем проекте?
#76 by vi0
ну ты отвечаешь на , мне интересны именно детали реализации
#77 by Bober
чтобы можно было крутить данные как того требуется бизнес на предельных скоростях платформы.
#78 by Маратыч
Дык понятно же для чего. По т.н. "не РИБ" данные сливаются в центр независимо от обновлений конфы, можно это делать часто, ограничив обмен первичкой и т.д. Второй план - для еженедельного обновления конфы, ну и ночной выгрузки НСИ в периферию.
#79 by Обработка
как может "РИБ" иметь "неРИБ"??? Можно мозг сломать. Подправьте тему кто может...
#80 by Фрэнки
У меня получилось так. Есть некоторая значимая часть НСИ - их относительно не много, но они критичны для нормального запуска сеансов пользователей и последующих обменов. Тем более, что у меня предусмотрен вариант многоуровневого погружения, скажем так. Я наличие таких НСИ связал с РИБ и идет их трансляция только от центра у узлам. А есть еще планы обмена, связанные с произвольно создаваемыми узлами в них. Т.е. внутри объектов узел в ТЧ прописаны соотв разделители. Все данные от узлов для центра регаются только под этими планами. И можно создать самые причудливые вариации, например: это подразделение и вот это выгружу и еще одно - по узлу А1, а вот это только одно подразделение - по узлу Б12. Ну в ответку могут, на практике, идти корректировки всех данных из центральной базы, если такая необходимость возникает. Вообще, т.к. в обратную сторону поток данных существенно меньше, возвращаются исправления без особых проблем. Т.е. у меня в планах обмена физическое количество периферийных баз не равно количеству узлов обмена и количеству планов обмена. И между прочим, в самых последних новациях по практическому использованию КД 3 можно увидеть ровно такой же методический подход.
#81 by Фрэнки
И дополню чуток по периферийным базам: какая-то часть узлов обмена выделена в периферийные базы, поскольку обособленные подразделения там на нестабильном инете живут, а в некоторых периферийных базах узлов обмена по нескольку штук и обособки оперативно работают в них дружно. При небоходимосьти  представители обособок (пользователи) могу входить в центральную базу и редактировать свои документы прямо в ней, такой функционал обеспечен полностью для всех пользователей любого узла. И да, передается в центр справочник пользователей, а не пользователи иб, т.е. перед началом работы в центральной базе любого пользователя иб нужно по готовому элементу из справочника пользователей создавать пользователя иб ручками.
#82 by Bober
я убираю все с плана обмена РИБ (который овечтает из отправку изменений конфигурации) и реализовываю обмен НСИ или другими критическими для бизнеса объектами через второй план обмена с классической сериализацией (или можно уже через json). При таком подходе  можно реализовывать безумную логику, которая классическому РИБу и не снилась никогда. примеры: - конфигурация изменена, но нужно срочно прогрузить изменения цен, добавление новых элементов справочников. - работа с вебhttp сервисы c пообъектной выгрузкой - реализация сложной выгрузкизагрузки цепочки объектов как одного целого. - отказ от добавления в план обмена регистров подчиненных регистратору и при этом частичная выгрузка. - и тд, там можно бесконечно перечислять . PS ну и классика, решение проблем с блокировками при обменах.
#83 by vi0
> отказ от добавления в план обмена регистров подчиненных регистратору и при этом частичная выгрузка Какую здесь роль играет наличие двух планов обмена, а не одного?
#84 by Bober
в классическом РИБе нужно регистрировать изменения не только документа, но и его движения для обмена. Соответственно будет дольше блокировка при начале обмена и сложно сделать исключение из обмена определенных движений для определенных узлов. При двух планах обмена можно вообще не добавлять регистры в состав второго плана.
#85 by vi0
> При двух планах обмена можно вообще не добавлять регистры в состав второго плана. ...и выгружать их своим кодом вслед за документом?
#86 by Маратыч
Документ проводить при загрузке, например.
#87 by Лефмихалыч
например, чтобы обновление конфигурации не зависело от данных. Или, чтобы легче и гибче было управлять тем, какие данные будут в центре. Еще, несколько планов обмена создают, чтобы разными данными с разной регулярностью или/и разной интенсивностью. Да много для чего. каких деталей тебе надо?
#88 by Bober
да вслед за этим идет выгрузка подчиненных объектов. например движения, регист сведений свойства объекта и тд. в подчиненной базе это все записывается в единой транзакции.
#89 by vi0
Коллеги, правильно я понимаю, что проблемы блокировок возникают именно при чтении в ЦБ, не при записи?
#90 by vi0
+ проблемы, которые вынуждают создавать два плана обмена и прочие ухищрения
#91 by Маратыч
Да дело не в проблемах, а в обычном здравом смысле при построении звездной архитектуры РИБ с кучей перифериек оперативных. Проблемы-то с блокировками, может, и есть, но в большинстве случаев банально ни к чему гонять кучу ненужной информации с высокой частотой туда-сюда, да еще и со всеми изменениями конфы.
#92 by vi0
но у меня вопрос именно про блокировки
#93 by Маратыч
Если используешь управляемые блокировки с соответствующим уровнем изоляции, тогда блокировок можно избежать. Иначе они будут и при выгрузке, и при загрузке данных.
#94 by Serg_1960
Имхо, самое "слабое звено" - это таблицы регистрации изменений. Работа с ними (и проблема блокировки естественно) происходит как во время выгрузки данных, так и во время загрузки данных одновременно с работающими пользователями, которые тоже претендуют на регистрацию изменений в эти же самые таблицы. Вероятность возникновения конфликта всегда есть, от этого не уйти. Почитай, подумай:
#95 by vi0
не увидел там ответа на свой вопрос из задал вопрос из-за такого простого теста: - Создал базу ЦБ с двумя узлами пб1, пб2 - в ЦБ делаю выгрузку изменений в пб1, делаю останов выгрузки в процедуре ПриОтправкеДанныхУзлаПодчиненному - во втором сеансе ЦБ делаю выгрузку изменений в пб2, которая прерывается по ошибке "Конфликт блокировок". Аналогичная же паралельная загрузка в ЦБ, с остановом в ПриПолученииДанныхОтПодчиненного выполняется без проблем. Понимаю, что это не нагрузочное тестирование, но мне интересно, что принципиально в ЦБ параллельно писать можно. Или нет?
#96 by Bober
да, при выгрузке данные самые большие ожидания на блокировку при типовом подходе к работе с РИБ.
#97 by Фрэнки
это у тебя какие узлы? одного и того же плана обмена? да еще и включенным РИБ ?
#98 by Фрэнки
естественно, что включенный риб блокирует основную свою системную таблицу, через которую у него идут отметки о выгрузке-загрузке конфигурации, причем блокирует это все транзакция. Новый обмен просто не сможет начаться.
Тэги:
Ответить:
Комментарии доступны только авторизированным пользователям

В этой группе 1С