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

(0) Сделай структуру базы типа "дерево"

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

(1) (2) Я подумал об этом, но пока абстрактно. Может быть, у кого-то будут критерии "агрегации".

+(2) ага.
Если в сутках 24 часа = 1440 минут.
На каждый обмен можно выделить не болшье 1.4 минуты....

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

Все зависит от более конкретных данных.

(4) блокировки будут? данные разных узлов не пересекаются, или я ошибаюсь? Сервер БД MS SQL

что-то это мне напоминает... салоны мтс, вроде
вариантов организации все равно несколько
дерево,
хитрые сильно перепиленные/пожатые обмены,
итп
1+ минута это много - отчет ККМ за сутки 1 придет, ну максимум еще инвентаризация 1 крупным документом, обратно все 1К товаров уедут... если в обменной базе кроме обменов никого то все и так работать будет при запуске по очереди
в параллели блокировки будут

(0) Ведите все в одной базе.

И что такое "пара зионов" ???

(9) Xeon /?zi??n/

(0) это что у вас за торговая сеть такая? Магнит, пятерочка, другое???

(0) не будет в таком варианте работать.
более 100 узлов на одну базу - считаю не реально. Могут быть конечно исключения. Но если ты задаешь подобный (0) вопрос - не реально.

(7) в целом похоже. центральный узел будет только собирать данные из распределенных узлов, и обмениваться с УТ

(10) Сколько пользователей ?

(12) личный опыт, или интуиция? в чем затык?
(14) в этой базе никаких пользователей, только обмены
(11) "другое", номенклатура меньше

объемы большие будут? накопите террабайт в центре, и тут изменение структуры регистра с пересчетом... и все встает колом "пусть весь мир подождет"

я бы делал примерно так, 1 промежуточный узел на 50-70 конечных. Итого в центральном узле будет 17-20 узлов укрупнённых

(16) хотелось бы забить продажами такие объемы, но вряд ли :)

(16) вариант отказа от стандартных механизмов обмена я тоже рассматриваю

микро-сервисы

(20) сравнимо

>в этой базе никаких пользователей, только обмены

обмены кого с кем? если просто некая инфа туда сюда гуляет - накуа вообще 1С

(19) и это наверное правильно. В стандартных механизмах блокируются таблицы изменений, в паралельности кирдык.

http://v8.1c.ru/overview/RaspredBases.htm
Вообще видел сеть основной узел у него порядка четырех подчиненных и в эти подчиненные в твоем случае повесишь по 25 магазов

(22) см (13)

http://v8.1c.ru/overview/images/shema_18.gif

Просто когда все сто магазов постучатся в основную пользователи могут идти курить

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

(28) Полный обмен по 33 подчинённым узлам за пол дня работы выполняется примерно за 40 минут. Объем передаваемых при этом данных в обе стороны суммарно порядка 20 мегабайт в архивах.

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

в итоге будет хоть 2к узлов работать в основной базе.

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

(30) можно вопрос, как при
>> параллельной загрузке через фоновые задания и
>>отказе от стандартного механизма выгрузки- загрузки при РИБ от 1с
вы будете вгружать измененный CF в 2к узлов?
или это все просто теория: запустились и не обновляем конфу вообще?

(0) Не страдайте фигней, все будет зависеть от кол-ва новых/измененных доков и строк в них

Есть опыт (правда 8.1 а не 8.3) со 170+ периферийных баз и полет нормальный за 4-6 часов обмен обычно делался - это если хорошо наколотили накладных (порядка 2-3 на базу) и обратно доков (порядка 100-200) за день

(31) написано же - каждый узел свои остатки получает

(30) одна проблема.
"  - параллельная загрузка через фоновые задания " - в 1С не работает

А все потому что кому то в 1С было сделать лень управляемые блокировки на таблицу изменений

(35) все работает, откуда такая информация? Нужно уметь готовить.

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

Есть реальный опыт:
ЦИБ - на УТ (sql)
ПИБЫ (сейчас 900) - на РТ, причем файловые РТ

Выгрузка/загрузка обменов - параллельно в фоновых заданиях (несколько потоков).
Из ЦИБ едут: приходы, цены, основные справочники
из Рт: ОРП, инвентаризации, ПТО (приходный товарный ордер)

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

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

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

+(40)
Обмен УТ-РТ - используется типовой план обменов + частично пиленные правила, но там просто некоторые блокирующие проверки + контроль зарегистрированных изменений.

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

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

Правда БП в этом плане вообще дурная конфа, ибо при проведении документа он делает движения по 2-3 регистрам максимум, а регистрирует для выгрузки еще минимум 20-30 пустух регистров

(39) Здесь наверное  можно только администрированием целыми днями заниматься  и ловить рассинхронизации...

+(45) Имха РИБ уже прошлое ....

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

(46) ага, особенно с нашими реалиями по интернет доступности и устойчивости...

(47) речь то о том чтобы параллельно блокировать одну и туже таблицу

(38) РБД использовать для 1000 узлов считаю не реальным.
изменения конфы будут очень долого выгружаться

конфа должна централизовано обновляться. Проще всего реализовать - сразу вся

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

Дерево. Только дерево с неменее 2 уровней.

Все зависит от сценария использования центрального узла. Можно даже платформенным механизмом РИБ воспользоваться.

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

(50) там проблема в регистрации изменений, а не в механизме загрузки

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

(55) Это как?
У тебя грузится пакет которые регистрирует изменения справочника номенклатуры, и помечаетдля выгрузки по узлам
Паралельно грузится другой пакет, скажем с подтверждением загрузки номенклатуры при прошлом обмене

Что значит одним махом если пакеты не знают о существовании друг друга

(56) файлы можно и самому читать, в обход стандартной загрузки

Есть варианты обхода блокировки таблицы изменений - писать в РС. Потом из РС в план обмена переносить. Можно пробовать реализовать.

Но есть и удачные примеры отказа от РИБ и перехода на управляемые формы.

(49) блокировки чаще всего ничтожно мелкие (если использовать типовой механизм регистрации при записи объекта), при загрузке данных из подчиненных проблем нет.
PS я не предлагаю использовать типовых механизмы выгрузки - загрузки РИБ, у которых из возможностей только управлять количеством элементов в транзакции.

(57) да, это один из рецептов оптимизации загрузки.

(58) у упр форм только и одна только один минус - это зависимость от канала связи.