Ситуация:
Сейчас есть одна база. Скоро добавится ещё одна. Потом ещё несколько. 10-20-30 штук будет со временем. По всей России, в разных точках.

Конфигурация у всех баз будет одна.

Обмен будет только некоторых общих данных, которые нужны для работы в каждой базе (справочники, ПВХ, регистры сведений). Эти данные будут добавляться только в одной базе, из которой будут расходится по остальным.

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

База нетиповая. Платформа 8.3.26. Стоит БСП 3.1.11.

Вопрос - как лучше будет обеспечить единство конфигураций? Видится варианты через РИБ или все базы подключать и обновлять из одного хранилища.

Сейчас схема работы такая - с базы разработки изменения помещаются в хранилище, потом, раз в сутки, изменения из хранилища накатываются на боевую базу.

В схеме с РИБ нравится, что конфигурация ходит сразу в сообщении обмена и вроде как не будет такого, что придут данные, а база не обновлена. Из нюансов - больше время на передачу сообщения с конфигурацией.
Ещё условно возникают отношения главная база - подчиненные, хотя если смотреть по документообороту и значимости, то они примерно одинаковы, но это условность. Общие данные всё равно будут вноситься только в одну базу.

В варианте с одним хранилищем нравится простота. Но кажется, что может быть такое, что база не обновится, а сообщение с данными к ней уже придут. При этом можно будет обеспечить обновление всех боевых баз в одно время. Но в теории какая-нибудь база может обновляться дольше или скрипт не отработает или ещё что-нибудь техническое. Непонятно.

И кажется странным, что если можно все базы цеплять к одному хранилищу, то зачем бы вообще выдумывали РИБ. Но при этом в интернетах что-то не особо информации нашёл о таком решении.

Что думаете? Может, есть опыт в реализации и той и другой схемы и знаете подводные камни, плюсы минусы?

(0)

1) Я так понимаю, опыта эксплуатации РИБ, и обновления конфигураций по РИБ у вас нет.

Вы забыли про вариант:
-- вчера было обновление.
-- ночью обновление автоматом накатилось на рабочую базу
-- Затем выгрузилось в файлы обмена в кучу РИБ-ов
-- 20 РИБ-ов из 30 обновились успешно

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


Это из опыта эксплуатации УТ10 на (10 ?) РИБ-ах более 15 лет тому назад.

Сейчас конечно всё по другому, быстрее и надженее (это сарказм)

2) >>База нетиповая
Если её писали вы - то ССЗБ
Но если с помощниками, то вас возможно ждёт куча опыта


3) Надеюсь базы (на местах) не файловые

(0) Единая база с включенным разделением данных. Да-да, как во Фреше

(1) да, с РИБами опыта нет.

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

И если база не обновилась, то это ведь нужно будет в любом случае решать и обновлять её?

И есть какой-то способ обмена, у которого этих проблем нету?

На местах базы не файловые, везде сервера.

(2) Единую базу не очень хочется из-за большой географической распределенности.

И РИБ и хранилище конфигураций!

Хранилищ возможно потребуется даже несколько
Ну там: разработки, тест/препрод, релиз/прод
А еще для расширений так же

Кстати РИБ прекрасная штука и готовить ее совсем не сложно научиться
Даже если какие сбои - оно прекрасно лечится, можно как выводить базы из РИБ так и заводить в них

И да что базы в РИБ не исключает обмен данными мимо него
Это параллельные процессы

(1) 10 баз всего в РИБ?
Пфф у меня 160+ было в РИБ
Самый прикол это иерархическая связь, когда ЦБ общается с некой ПБ а та со своими подчиненными ПБ

(6) ну там в перспективе будет больше 10. Пока начинается все  с двух баз.
А "прикол" в смысле удобства или сложности, проблемами?

И вот в (1) обозначали проблемы с файлами.. с этим как было при таком количестве баз у вас?

(2)+1
Снимает кучу вопросов, даже при необходимости разделения и выдачи какой-то одной базы.
(4) Когда-то от Краснодара до Алтая работали. При нынешних ценах на связь могут себе позволить такое и весьма средние компании.

(0) Если будет не РИБ. Включите в пакеты обмена номер версии обмена. Будет меньше проблем.

(7) Прикол с иерархией был вынужденный
Структура подчинения + логистика
Ибо файлы обмена местами в совсем диких ипенях на флешках и болванках ездили, там где инета не было

Но да надо учитывать что современные типовые конфы часто не доделаны до нормальной работы РИБ
Не говоря уже про отраслевые и прочие сторонние решения и доработки

Например вот ЕРП например умеет в РИБ (с некоторыми исправлениями там где разрабы типовой например ЕРПУХ забыли)

Но если взять некую добавку-поставку для ЕРП типа "ГНИВЦ:Налоговый мониторинг" - накатили ее на ЕРП и вперед обмен для РИБ пилить
Прикол тут что встроенная "Налоговая витрина" в ЕРП штатно через РИБ пашет а добавка нет :)

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

Одно дело, когда базы клиент-серверные и все живут на одном сервере, куда пользователи подключаются удалённо. Тут можно и РИБ рассмотреть и фреш.
Совсем другое, когда имеем колхоз полный самых разношёрстных баз - у кого-то клиент-серверная база на отказоустойчивом кластере в датацентре с резервированием каналов связи, а у кого-то файловая база на пятилетнем ноутбуке, подключенном к сети по wi-fi, с мобильным интернетом уровня GPRS (жопорез)  и ближайшим айтишником в паре дней езды. В таком варианте РИБ я бы не рассматривал вообще ни под каким соусом - см.(1).
Отдельный вопрос с нынешним состоянием устойчивости связи в стране. Выделен ли бюджет на курьерские службы, которые будут доставлять обновления и данные на флешках, если завтра включат белые списки на проводном интернете.... Вопрос полуриторический-полушуточный (почти).

(9) По номеру версии обмена можно будет определять, надо ли конфигурацию обновлять?

(11) Понял, спасибо!
Но тк у меня не типовая, то все в моих руках будет

(4) И что? Есть неоднократный опыт единых баз с пользователями от Калининграда до Владика

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

Ну и если даже отходить от РИБ, то какой вариант вы бы рассматривали?
И что думаете по единому хранилищу?

(15) Нужно чтобы время отклика было минимальным. Запросы из Калининграда на сервер Владивостока будут явно дольше, чем из Калининграда на сервер Калининграда.

(17) А если всё на одном сервере, а звери через терминал работают, то не всё ли равно? Ну, немного тормознутых нужно брать пользователей, торопыги тут ни к чему.

(0) судя из описание использование в разных БД разных релизов решения является допустимым, раз так, то нужно использовать Обновлятор в качестве средства гарантированной доставки cf

(16) И что думаете по единому хранилищу?

А какое преимущество перед РИБ, если Вы его рассматриваете в качестве варианта?

Нужна просто одна база в облаке.

(20) в относительно простоте

(21) но тогда ведь все упрутся в доступность облака. Не будет ли оно "узким горлышком"?

если самописька в (0), то можно тупо версии сравнивать, как в (9) предложили

если в "обмене" версия не совпадает с "константой" в чисто конкретной локальной БД - то уже программно что-то там делать  - запрещать, сообщать, крашить или пренебречь и торгуем дальше

в обормотчики обновлений при обновлении пофигурации (вручную или с помощью Обновлятора (19)) предусмотреть изменение версии в "константе" чисто конкретной локальной БД после обновления пофигурации

в общем, как сделаешь, так и будет работать, если без РИБ

а в торгобле чувствительные данные (которые в "центральной" базе нужны срончо-срончо для каких-нибудь отчетов) - можно "пушить" через тырнет посредством API (ну там get или post). Можно также из центральной (самой пресамой главной) и "дыхание" проверять у периферийных

- Сифон, ты жывой? а я думал ты сдох!!

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

(23) Это гораздо проще, чем поддерживать 30 серверов, разбросанных по стране. Сделаете 2-3 зеркала и всё будет пучком.

(24) понял, спасибо!
А в решении РИБ какие видите недостатки?

(26) РИБ прекрасная задумка, когда еще не было http-запросов и Джопсонов (JSON) в платформе...

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

да много чего прикольного было, особенно когда еще и Расширения (сознания) в платформу 1С завезли

тема с РИБ рабочая на 146%, рекомендую

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

я бы много раз хорошенько подумал насчет РИБ...

(22) в относительно простоте

Хранилище поможет вам донести последние изменения до каждой базы, подключенной к нему. Допустим вы остановились на этом, как вам кажется, просто инструменте. Хорошо. А данные как вы будете консолидировать - каким механизмом? Что за обмен?

(27) Вывести базу из РИБ и подключить к хранилищу - меньше часа
А вот завести в РИБ - нюню

Так что сначала советую планировать и попробовать на РИБ
Если не получается то отказаться от него легко, если параллельный обмен данными уже есть как правильно замечено в (28)

Так что лучше сразу делать РИБ + храны (в котором пока только ЦБ) + параллельный обмен данными на http и json (не забыть синхронизацию по УИД обязательно как в РИБ)
И нежелательно использовать для новых проектов (особенно самописки) старый КД на xml

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

Если есть стабильное соединение, то действительно лучше всё развернуть на одном сервере, а обновлять скриптами (или через хранилище, или формировать поставку).

(29) Понял, спасибо!

(30) Даже на одном сервере много юзеров в одной базе это проблемы и тормоза
Не лучше ли держать разные РИБ базы даже на одном?

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

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

(34) Любая нагрузка
Попробуй выгнать из базы 10 пользователей для обновления одной из 10 баз, когда остальные 90 пользователей могут продолжать работать
И попробуй сразу 100 пользователей выгнать из одной базы ))

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

РИБ, РИБ, нафиг ваш РИБ)

(35) а в чем сложность то? у нас сервер 1С всех выгоняет, когда включаешь блокировку с: по: и даже за 5 минут всем пользователям напоминает клеент: рекомендуется сохраниться и завершить работу

кто не спрятался - сервер не виноват

можно даже автоматизировать

(35) У меня 350 было, и выгонялись на раз. Да и проблемы индейцев белого шерифа не волнуют.

(29) > А вот завести в РИБ - нюню

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

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

УИД базы надо еще будет заменить у обрезка, желательно

ОбновитьНумерациюОбъектов() еще не помешает :)

(38) Неа
Бывают случаи сбоев/зависаний подключений когда не получается выгнать без перезапуска сервера

Например длительный серверный вызов который не завершается пока сам не упадет
И чем больше юзеров в базе тем вероятность такого выше

Как и ожидания пока все выйдут после предупреждения
Если тупо начать рубить всех - кому нравится потом вопли слушать или с ошибками разбираться в базе?

(40) > Если тупо начать рубить всех - кому нравится потом вопли слушать или с ошибками разбираться в базе?

письмо на электропочту, как в анекдоте про девушек, которые любят внимание

- внимание! сейчас будет sex

(39) Очень смешно да
Когда база большая выгрузка ПБ из ЦБ тупо или много часов (до суток и более) или никак
А как работать в это время?

(41) Ты любитель извращений и пожесче?

(42) не делал чтоли так ни разу?

из копии центральной по-бырому (магией скуля)

только по феншую?

(44) На субд не пускали там

(43) у нас всё регламентировано, если не какая-нибудь авария

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

(40) Если не начинать персонально уговаривать отдельных не закончивших работу, то после пары-тройки обломов и разборов полётов все выходят без второго предупреждения. Ну, и главное, обновляться нужно в комфортное для пользователей время, то есть за пределами рабочего дня. А зато можно и попозже прийти на работу и пораньше уйти, и прочие плюшки.

(47) фигня иногда случается... но это аварии

понять и простить

спланировать время и сколько это займет точно - тоже надо уметь

у нас есть мееедленный сервер разработки и дерзкий шустрый сервер продуктива

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

(48) За решение этих пустячков, собственно, нам и платят денежку. Если бы не нештатные ситуации, то на кой мы нужны тогда.

(49) ну я х.з.

погромисты в штате еще бывают нужны для изменения ландшафта (пока враги рисуют карты)

(50) Я за свой оклад готов и стоянку подмести, да вот начальство не готово.

(51) > для изменения ландшафта

из типовой методом ХХП сверху и сбоку делать нетиповую, уникальную - я про доработки по желанию начальства

(51) а вы сильный программист?

тогда помогите вот ящики из машины разгрузить