Когда заканчивается Enterprise Data и начинается RabbitMQ ?
Добрый день Коллеги! поделитесь опытом пожалуйста!
когда заканчивается целесообразность продолжать эксплуатацию типовых Enterprise Data и желательно переходить на какие либо иные интеграционные инструменты или шины ?
где этот предел? документировано ли это?
мои требования - обмен малым объемом но с большим количеством узлов (40-150) и относительно часто(5-15минут) .
я получаю проблемы которые похожи на описание блокировок таблиц изменений, пока не проверил.
но возможно эти оптимизации не уместны в рамках типовой архитектуры построенной на планах обмена и из них больше не "выжать" и надо сразу прилагать усилия для перехода на RabbitMQ , 1С:Шина и тп.
поделитесь опытом пожалуйста, каковы Ваши практики?
в приложенном файле я описываю возникшие проблемы и 3 возможных сценария оптимизации. насколько подходы адекватны?
например для Enterprise Data следующие настройки доступные для управления из коробки:
Транспорт - файл, http, com
Расписание сценариев
Количество одновременных синхронизаций
Размер передаваемых данных
из неявных
-параметр "количествоЭлементоввТранзакции",
-правила выгрузки-загрузки которые могут работать медленно и это может являться полем оптимизации(какие нибудь циклы, поиски, подборы).
-стратегия регистрации объектов которая может влиять на объем передаваемых данных.
я теоретически могу этими параметрами управлять не снимая конфигурацию с "замка" и не делая доработок.
но и у этих обменов есть ограничения:
XDTO + COM
например мой опыт - нельзя иметь 120 синхронизаций по COM с расписанием 1 раз в 10 минут при 30 одновременных подключениях из Центральной базы в периферию.
теоретически это даст возможность за 40 минут сделать синхронизацию со всеми 120 узлами, но на практике ....далеко нет.
XDTO + HTTP
скажу честно - не пробовал, не моделировал, опыта нет. но там все тот же план обмена с его ограничениями и я сомневаюсь что парни из 1с "приготовили" его как-то по другому.
когда заканчивается целесообразность продолжать эксплуатацию типовых Enterprise Data и желательно переходить на какие либо иные интеграционные инструменты или шины ?
где этот предел? документировано ли это?
мои требования - обмен малым объемом но с большим количеством узлов (40-150) и относительно часто(5-15минут) .
я получаю проблемы которые похожи на описание блокировок таблиц изменений, пока не проверил.
но возможно эти оптимизации не уместны в рамках типовой архитектуры построенной на планах обмена и из них больше не "выжать" и надо сразу прилагать усилия для перехода на RabbitMQ , 1С:Шина и тп.
поделитесь опытом пожалуйста, каковы Ваши практики?
в приложенном файле я описываю возникшие проблемы и 3 возможных сценария оптимизации. насколько подходы адекватны?
например для Enterprise Data следующие настройки доступные для управления из коробки:
Транспорт - файл, http, com
Расписание сценариев
Количество одновременных синхронизаций
Размер передаваемых данных
из неявных
-параметр "количествоЭлементоввТранзакции",
-правила выгрузки-загрузки которые могут работать медленно и это может являться полем оптимизации(какие нибудь циклы, поиски, подборы).
-стратегия регистрации объектов которая может влиять на объем передаваемых данных.
я теоретически могу этими параметрами управлять не снимая конфигурацию с "замка" и не делая доработок.
но и у этих обменов есть ограничения:
XDTO + COM
например мой опыт - нельзя иметь 120 синхронизаций по COM с расписанием 1 раз в 10 минут при 30 одновременных подключениях из Центральной базы в периферию.
теоретически это даст возможность за 40 минут сделать синхронизацию со всеми 120 узлами, но на практике ....далеко нет.
XDTO + HTTP
скажу честно - не пробовал, не моделировал, опыта нет. но там все тот же план обмена с его ограничениями и я сомневаюсь что парни из 1с "приготовили" его как-то по другому.
По теме из базы знаний
Ответы
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(1) Насколько я понял у Вас РИБ, состоящая из узлов на БП.
1. Enterprise Data - это формат кодирования сообщений. Сам по себе он не влияет на блокировки, регистрацию изменений, транспорт и прочее. Единственный вариант, когда его нужно оптимизировать, при чём скорее всего исключительно по размеру сообщения, это какая-то сверх-жёсткая оптимизация. До такого ещё надо дожить.
2. Вы правильно поняли, что проблема в блокировках на таблицах регистрации изменений. Так работает механизм планов обмена. Пропускную способность этого механизма можно оценивать по разному, но реальная оценка - замеры производительности. Конкретные цифры по блокировкам, объектам и прочее. До тех пор, пока это устраивает - пользуемся.
Возможны микро-оптимизации, которые могут позволить достичь нового уровня пропускной сопособности с приемлемыми показателями эксплуатации. Обычно максимум на 20%.
Мой обобщённый опыт (средняя температура по больнице) - планы обмена могут приемлемо работать в сетях до 100+/-20 узлов.
3. БП - это планы счетов и регистры бухгалтерии. Это ещё один фактор блокировок при проведении документов. Это отдельная тема как распараллелить проведение документов. К обменам напрямую не относится, но естественно с этим косвенно связана.
4. Отказ от планов обмена повлечёт за собой необходимость решать следующие вопросы:
4.1. Система регистрации изменений:
4.1.1. Регистрация изменений с данными.
4.1.2. Регистрация изменений без данных (только ссылки).
4.1.3. Обмен событиями (ещё одна другая тема).
4.2. Транспорт и гарантии транспортной системы:
4.2.1. Гарантии доставки.
4.2.2. Последовательность доставки.
4.2.3. Способ доставки (пакеты или отдельные объекты).
4.3. Загрузка данных (обычно это самое узкое место).
5. Эволюционный путь развития - лучший путь. Не факт, что Ваша система вырастет до 100, 500 или 1000 узлов. Предполагать каким путём пойдёт Ваша эволюция конечно же нужно, но форсировать точно не стоит, так как стоимость разработки системы обмена для 100 и 1000 узлов отличается на порядки. Есть такое мнение, что разработка нового уровня функциональности системы стоит 10 в n-степени от стоимости пердыдущей. То есть первый уровень стоит 10, второй - 10 во 2 степени, третий - 10 в третьей степени и так далее.
6. Коротко отвечая на вопрос в заголовке темы: 100 узлов, далее отказ от механизмов планов обмена.
1. Enterprise Data - это формат кодирования сообщений. Сам по себе он не влияет на блокировки, регистрацию изменений, транспорт и прочее. Единственный вариант, когда его нужно оптимизировать, при чём скорее всего исключительно по размеру сообщения, это какая-то сверх-жёсткая оптимизация. До такого ещё надо дожить.
2. Вы правильно поняли, что проблема в блокировках на таблицах регистрации изменений. Так работает механизм планов обмена. Пропускную способность этого механизма можно оценивать по разному, но реальная оценка - замеры производительности. Конкретные цифры по блокировкам, объектам и прочее. До тех пор, пока это устраивает - пользуемся.
Возможны микро-оптимизации, которые могут позволить достичь нового уровня пропускной сопособности с приемлемыми показателями эксплуатации. Обычно максимум на 20%.
Мой обобщённый опыт (средняя температура по больнице) - планы обмена могут приемлемо работать в сетях до 100+/-20 узлов.
3. БП - это планы счетов и регистры бухгалтерии. Это ещё один фактор блокировок при проведении документов. Это отдельная тема как распараллелить проведение документов. К обменам напрямую не относится, но естественно с этим косвенно связана.
4. Отказ от планов обмена повлечёт за собой необходимость решать следующие вопросы:
4.1. Система регистрации изменений:
4.1.1. Регистрация изменений с данными.
4.1.2. Регистрация изменений без данных (только ссылки).
4.1.3. Обмен событиями (ещё одна другая тема).
4.2. Транспорт и гарантии транспортной системы:
4.2.1. Гарантии доставки.
4.2.2. Последовательность доставки.
4.2.3. Способ доставки (пакеты или отдельные объекты).
4.3. Загрузка данных (обычно это самое узкое место).
5. Эволюционный путь развития - лучший путь. Не факт, что Ваша система вырастет до 100, 500 или 1000 узлов. Предполагать каким путём пойдёт Ваша эволюция конечно же нужно, но форсировать точно не стоит, так как стоимость разработки системы обмена для 100 и 1000 узлов отличается на порядки. Есть такое мнение, что разработка нового уровня функциональности системы стоит 10 в n-степени от стоимости пердыдущей. То есть первый уровень стоит 10, второй - 10 во 2 степени, третий - 10 в третьей степени и так далее.
6. Коротко отвечая на вопрос в заголовке темы: 100 узлов, далее отказ от механизмов планов обмена.
(1)Как только вы разделите процессы сериализации данных от транспортирования этих самых данных, так все встанет на свои места.
ED - это формат/способ сериализации данных
RMQ - это формат/способ транспортировки данных.
Вот асинхронные действия для ускорения обмена:
1. Используйте планы обмена в качестве хранилища измененных объектов,
2. Реализуйте очередь исходящих сообщений и снимайте регистрацию с объекта после помещения в очередь
3. Сериализуйте объект
4. Передайте сериализованный объект, примите данные и поместите в очередь для десериализации данных и превращения их в объекты БД.
ED - это формат/способ сериализации данных
RMQ - это формат/способ транспортировки данных.
Вот асинхронные действия для ускорения обмена:
1. Используйте планы обмена в качестве хранилища измененных объектов,
2. Реализуйте очередь исходящих сообщений и снимайте регистрацию с объекта после помещения в очередь
3. Сериализуйте объект
4. Передайте сериализованный объект, примите данные и поместите в очередь для десериализации данных и превращения их в объекты БД.
ED заканчивается на формировании сообщения, RabbitMQ начинается на отправке сообщения.
Если вы не регистрирует изменения, то не имеет возможность гарантировать отправку объекта, так как регистрация происходит в одной транзакции с записью, а отправка, очевидно, нет.
Если вы не регистрирует изменения, то не имеет возможность гарантировать отправку объекта, так как регистрация происходит в одной транзакции с записью, а отправка, очевидно, нет.
Чтобы понять ценность и место кролика, надо вернуться к тому, как 1С гарантирует доставку сообщений. Платформа гарантирует это тем, что очистка регистрации изменений происходит только тогда, когда мы получаем ответное сообщение, в котором указано, до какого именно, включительно, сообщения данные точно получены. Потому что ни один стандартный транспорт не гарантирует доставку сообщения (даже web).
Что нам дает очередь? Гарантию того, что сообщения будут доставлены и в нужном порядке. А значит мы можем снимать данные с регистрации сразу после того, как они помещены в очередь. А мы можем подобрать частоту отправки так, чтобы сообщения были минимальны и соответственно блокировки тоже.
Что нам дает очередь? Гарантию того, что сообщения будут доставлены и в нужном порядке. А значит мы можем снимать данные с регистрации сразу после того, как они помещены в очередь. А мы можем подобрать частоту отправки так, чтобы сообщения были минимальны и соответственно блокировки тоже.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот