Что лучше, красное или солёное, или 1 база vs 109? #545150

Имеется небольшая федеральная сеть из 109 филиалов. Предполагается создание выделенного сервера в Москве и работа около 250 пользователей из этих филиалов удаленно (тонкий клиент или терминал). Конфигурация самописная, на управляемых формах.   Вопрос в том, создавать ли для каждого филиала отдельную базу в 1С (на основе MS SQL) или создать единую базу (с раздельным учетом по филиалам), где будут работать 250 пользователей?   Как такие варианты различаются по производительности? Сами склоняемся все же к варианту с созданием отдельной базы для каждого филиала, несмотря на очевидную сложность обслуживания (обновлений итп.) такого количества баз.   Но тем не менее, может у кого есть успешный опыт эксплуатациии одной базы 1с 8.2 Управляемого приложения, в которой работало бы свыше 200 пользователей удаленно?  Кроме того, понимаю, что тема баян, но всё же, что для такого масштаба будет предпочтительнее: терминал или тонкий клиент, может какие новости появились с момента последних обсуждений таких тем?  Спасибо.

терминал конечно и одна база

Ну если учесть что 40 юзеров на УФ из городов + 10 юзеров тут в обычных формах, в УПП  + пачка торговых кидают заказы в базу с КПК, и всё это вполне нормально работате, то, думаю не нужно 109 огородов городить...

т.е. я хотел сказать что не 100 баз. а тонкий или толстый клиент или вэбклиент я не знаю

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

Слишком жирно по целой базе на 2-3 человека, имхо.

Вот тут есть примеры технологических параметров внедрений: У кого-то и 400 пользователей одновременно работают...

На крайняк, сделайте штук 5 баз по регионам.

много зависит от качества связи... у меня порядка 50 магазинов по россии, у каждого своя база, в каждой 10-20 пользователей + центр около 100, есть пару магазинов где вечно проблемы со связью... у остальных редко... но что то случается по всяким причинам... сажать их в одну базу? .... не... лучше пусть каждый в своей варится...

Тонкий клиент и одна база. Где голосувалка:

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

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

В крайнем случае централку можно пустую оставить и использовать её только для обновления конфы. Но я бы полную миграцию туда делал. Сводная база по-любому пригодится.

Опять-таки, если по крайней мере брать файловую версию, то всегда заметно, как по мере роста объема базы, происходит падение скорости работы.   Справедливо ли это для клиент-серверного варианта на скуле? Ведь объем базы, где работают 2-3 юзера не будет так быстро расти, как в случае 250-ти. В том то и прикол, что начальство на отрез РИБ не хочет. Сейчас учет до сих пор ведется на семерке во всех 109 филиалах. Руководство бы хотело, чтобы базы (база) лежали бы в одном месте и в случае необходимости можно было бы онлайн проследить, какаой юзер из какого филиала сейчас в базе, сколько он за день выполняет итп, и кроме того, чтобы никто не мог заходить в закрытые периоды (а в семерке достаточно заплатить местному умельцу из провинции пару тыщ и он период открывает).

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

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

Наши внедрюки написали "Обновременно подключаются 70 пользователей". Хотя 2 хаспа 50 + 20 не есть "одновременно".

Как бесконечно далеки все от народа :) нет такой связи во всех филиалах, чтобы гарантировать непрерывную работу и соответственно простои по вине ИТ отделов :)

С одной базой смущают 2 ситуации: 1. Лёг центральный сервер с базой. Вне зависимости от причины. 2. Лёг канал на центральный сервер. В обоих случаях чьи-то запчасти поджарят или возьмут за больное. Больше нравится идея про региональные базы. Тут надо смотреть по структуре конторы. Кстати, по поводу слияния информации можно направить взгляд в сторону репликиций sql. Но тут нужно быть очень хорошим спецом в этом деле. Про обновления. В 8.2 есть механизм самостоятельного обновления конфы пользователями. Можно им попользоваться.

+ 100500 Эх, если бы по всей стране был толстый канал... Репликация SQL для 1С вроде не взлетит

Контора имеющая 109! филиалов может и спутниковый дуплекс поднять. Ну а если кто спутник собьет - обстоятельства непреодолимой силы.

Так я и говорю, что спец по sql должен быть правильный. Чтобы репликации осуществлялись только при совпадении версий. А так sql до фени 1с это или нет. Но с другой стороны, все данные в центральной базе не нужны. Поэтому лучше даже если база, где хранится объединённая информации сама подключалась к региональным и выкачивала нужную информацию.

естественно одна база на всех 109 баз - надо же такое придумать на свою задницу:)

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

Ну вообще-то работу с задними периодами можно и запретить поумнее...

Невнимательно прочитал . При таком подходе огребёте в любом случае. Консолидация - дело последнее. Пока одни будут париться с внедрением всего этого в этих 109 местах. Другие за это время успеют написать конфу и при этом хватит времени и на чай и на то, чтобы в контру порубиться. Рекомендую податься в группу разработчиков этой конфы.

гы.. каждому одну базу... 200 человек - 200 баз.. а чо.. новое слово в проектировании инфраструктур...

а некоторым по 5 баз... А главнюку 200 баз, чтоб жизнь медом не казалась и не надо ни каких центральных :) и под каждую базу по серверу...

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

спасибо за интересную мысль ,, жгёте, парни )))

Все-таки хотелось бы узнать, наблюдается в клиент-среверной базе падение производительности по мере роста объёма, так же как в файловой? Я понимаю, что 109 (и более)) баз звучит несколько апокалиптически )) ну ведь проблемы негров шерифа не волновали никогда. В данном случае шерифу (руководству) нужна будет приемлемая скорость работы. А как уж там обслуживаться это дело будет им до лампочки...

Ты только не забудь потом отписаться, как это всё будет происходить. Заведи  блох, точнее блог. и там всё по дням. Читателей будет много. Если проект не взлетит, то на рекламе деньжонок срубишь. Так ты эмуляцию сделай. Поставь конфу, напиши бота, который тебе будет создавать документы или элементы справочников. И запусти его 109 раз. Вот и посмотришь.

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

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

все не так срочно-критично. Переход на новую систему предполагается не одновременный для всех 109 филиалов, а постепенный. На первом этапе предполагается тестирование на базе одного филиала, опытная эксплуатация. К  тестированию же в клиент-сервере приступим в ближайшие дни, еще до эксплуатации на тестовом фидиале. Никто в омут сголовой не бросится.

"Так ты эмуляцию сделай. Поставь конфу, напиши бота, который тебе будет создавать документы или элементы справочников. И запусти его 109 раз. Вот и посмотришь" Я другое имею ввиду, а именно: рост объема базы, где работают 2-3 пользователя будет несравнимо ниже того же для 250 пользователей. В файловой базе связь между объемом базы и скоростью работы очевидна (больше база - ниже скорость). Настолько же ли это справедливо для клиент-серверной базы?

>> наблюдается в клиент-среверной базе падение производительности по мере роста объёма Учитывая, что у вас самописка, всё в ваших руках. Если сумеете грамотно написать, то ни каких проблем не будет и с 400 пользователями. Что касается вопроса "1vs109", то тут всё зависит от надежности каналов связи и уровня критичности временной остановки работы филиала(ов) из-за перерывов в связи. Может вообще имеет смысл сделать связь фронтофис-бэкофис. Фронтофис в каждом филиале свой (можно поднять РИБ без обмена документами, а только едиными справочниками), бэкофис - единая база, в которую регулярно выгружаются данные со всех фронтов (возможно каким-либо образом сгруппированные). Учитывая надежность отечественной связи, я бы предпочел отдельную базу в каждом филиале.

если голосовалка, то я против 109.

Ага. Упал сервак или канал связи в головном офисе и все курят, посылая клиентов, или выписывают документы вручную. Хотя собственно тут всё от бизнеса зависит. Очень многие виды бизнеса вполне допускают такую ситуацию. Короче тут определяющими должны быть потребности бизнеса и конкретные условия эксплуатации. А 1С-ку можно как угодно настроить - были бы только руки прямыми.

репликация, кластеризация, админы сисят, Адмбд - бдят.

Способов и методов море. ИМХО, автор не с той стороны подошел к решению проблемы. На самописке вопросы производительности могут встать только при кривых руках разработчиков и совсем гнилом железе. А вот постой филиала даже в течении часа из-за обрывов связи может стоить вполне реальных денег в некоторых случаях.

Специфика работы филиалов в принципе допускает простой до нескольких часов в отдельных случаях. Но такого, конечно, не хотелось бы...

При нормальном клиент-сервере в управляемом режиме (грамотно настроенных блокировках, оптимальных алгоритмах проведения) пара сотен пользователей смогут работать без проблем. На этом не зацикливайся. С файловой тут никаких параллелей, всё хорошо масштабируется. Я за вариант с сотней баз чисто из эксплуатационных соображений. Филиалы ведь все автономные по сути. Загонять всех в одну базу просто потому, чтобы легче было обслуживать - никакого смысла не вижу. Сотню баз обслуживать ненамного сложнее, если всё грамотно организовать. Зато плюсов куча: 1) любой филиал элементарно переводится на репликацию по почте и обратно в любой момент 2) базы можно раскидывать по сервакам как угодно - немерянный запас для масштабирования. 3) немерянная фора прогам на кривые руки (всё равно в каждой базе пользователей немного) 4) каждая база содержит только "свои" данные - т.е. даже потенциально никаких проблем с безопасностью и гемора с разруливанием доступов и видимостей.

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