ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?

[mazzy]

Цитата:

Сообщение от AlexMoskvichev

В нашем случае (в пике 50К сообщений по 2Кб) затраты на брокера (Apache ActiveMQ 5) вообще не ощущаются на общем фоне.Все время уходит на формирование сообщений и их обработку при приемке.

Причем если отправку еще можно ускорить, например запустив несколько потоков, то приемку нет. Единственные средства улучшения для приемки - пакетные сообщения и замена железа.
При этом пакетные сообщения усложняют отправку и не ускоряют ее никак (в одном потоке)

угу.

Цитата:

Сообщение от AlexMoskvichev

Возвращаясь к вопросу.
100500 сообщений по 1Мб (например) это почти 100Гб сырых данных. За какое время их передавать надо и как далеко?.

а почему по 1Мб?
я вроде написал "коллекция - список/массив/мап/контейнер/таблица"
В мире аксапты элементы коллекций это максимум размер страницы MS SQL = 8Кб
Очень-очень редко мемо поля до 4Гб. Но про это я бы обязательно сказал.

все-таки для мира аксапты хорошие допущения:
= размер элемента до 8кб
= размер буфера рабочего окна 64Кб (максимальный размер XML в WCF по умолчанию)
= размер коллекции более 100500 элементов

Цитата:

Сообщение от AlexMoskvichev

Если проблема в размере сообщений, можно попробовать их сжать при отправке.

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

Цитата:

Сообщение от AlexMoskvichev

Или вообще,
Write CSV -> 7zip -> SFTP -> 7zip ->Read CSV
Или более современно, в parquet
Может оказаться вполне быстро и автоматизировать не сложно.
Через WCF можно управляющие команды подать, с метаданными файла

файла? какого файла? каким магическим образом вдруг файл передался?

[mazzy]

Цитата:

Сообщение от Vadik

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

А ты в этом смысле понимаешь слово передать.
Нет, я не имел в виду транспортный уровень.

Да, надо было использовать глагол "отправить"
вопрос звучал бы "как правильно отправить".

Я имел в виду, что Аксапта (как endpoint) инициирует процесс подготовки и отправки данных в другую Аксапту (другой endpoint). В WCF это означает Аксапта должна заполнить коллекцию с элементами и вызвать какой-нибудь осмысленный метод для этой коллекции.

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

И WCF, и другие брокеры, насколько я знаю, все имеют ограничение на размер сообщения. Размер сообщения меньше, чем размер всех элементов.

вопрос - как правильно готовить, чтобы отправить (передать) свои данные другому endpoint.

современный правильный ответ - использовать потоки.
но в Аксапте нет потоков.

какой способ отправить много элементов коллекции является правильным для Аксапты?

[George Nordic]

Цитата:

Сообщение от mazzy

прирожденный продавец

Не только. Более того, продажами софта я не занимаюсь. Я за всеобщую цифровую грамотность.

Цитата:

Сообщение от mazzy

и как правильно делают упомянутые тобой решения?

упомянутые мною решения, как платные так и open source, делают одно - он реплицируют данные из системы А в систему В. В режиме, близком в режиму реального времени, хотя временной лаг все равно есть. Да, и это требует включения режима расширенного логирования, так как они читают логи, что BDA не всегда по нраву. И, некоторые, установки агента, что уже не по нраву и безопасникам.

• Если задача стоит "надо сделать так, чтобы в системе В мгновенно отображались данные системы А" - горячее копирование, личный кабинет, репликация баз данных и т.п. - то это только CDC.

• Если изменений не так много и скорость репликации не так важна, но тоже критична, то можно обойтись брокером сообщений.

• Если изменения необходимо синхронизировать раз в день или раз в неделю, то можно реплицировать таблицы bulk load или просто инкрементом передавать новые / измененые / удаленные данные.

Какое именно решение считать "правильным" зависит от задачи и от критичности скорости изменений. Да, еще есть критерий гарантированной доставки сообщений и двухсторонней репликации / разруливания конфликтов репликации, но это за рамками обсуждения, иначе еще про шины данных придется рассказывать, такие как IBM WebSphere.

С Уважением,
Георгий

[mazzy]

Цитата:

Сообщение от George Nordic

Не только. Более того, продажами софта я не занимаюсь. Я за всеобщую цифровую грамотность.

я тоже!

- пойдем простым логическим путём
- пойдем вместе!
https://www.youtube.com/watch?v=wK1fq2QZbRk

Цитата:

Сообщение от George Nordic

Да, и это требует включения режима расширенного логирования, так как они читают логи, что BDA не всегда по нраву.

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

во-вторых, я не зря упомянул ax2009 и ax2012
в ax2012 (в той самой, где перехерачили главную книгу) перехерачили очень много других таблиц. в результате ОЧЕНЬ много таблиц в ax2012 не совпадают с ax2009

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



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

Цитата:

Сообщение от George Nordic

Какое именно решение считать "правильным" зависит от задачи и от критичности скорости изменений. Да, еще есть критерий гарантированной доставки сообщений и двухсторонней репликации / разруливания конфликтов репликации, но это за рамками обсуждения, иначе еще про шины данных придется рассказывать, такие как IBM WebSphere.

начинается...
да, я тоже за грамотность.

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

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

Цитата:

Сообщение от George Nordic

• Если изменений не так много и скорость репликации не так важна, но тоже критична, то можно обойтись брокером сообщений.

• Если изменения необходимо синхронизировать раз в день или раз в неделю, то можно реплицировать таблицы bulk load или просто инкрементом передавать новые / измененые / удаленные данные.

Причём, ни фига НЕ "инкрементом"!
инкремент за dDOS'ит системы нафиг. Для аксапты характерны таблицы, в которых поля обновляются часто. Какая-нибудь последняя себестоимость в карточках номенклатуры, например.

[George Nordic]

Цитата:

Сообщение от mazzy

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

Это не совсем так, есть класс задач, когда по-другому - никак. Например, отображение проводки в личном кабинете. Это или CDC, или триггер на таблице. И там и там есть нюансы. Пример 2 - данные из транзакционных систем в MPP DB для решения оптимизационных задач - next best offer, подбор такси, "рекомендуем посмотреть", контекстная реклама и т.д.

Цитата:

Сообщение от mazzy

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

Для DAX - да, согласен и даже рассказал почему. Про "других разнородных клиентов" - я бы на был настолько категоричен, честно.

Цитата:

Сообщение от mazzy

инкремент за dDOS'ит системы нафиг. Для аксапты характерны таблицы, в которых поля обновляются часто. Какая-нибудь последняя себестоимость в карточках номенклатуры, например.

а насколько нужно ее часто реплицировать? Это и брокера убьет нафик. Плюс возможны будут варианты, когда изменение со старой себестоимостью придет позже сообщения с новой себестоимостью - не факт что брокер будет успевать доставить все по очереди(!) или приёмник - обрабатывать по очереди отправки. Значит, еще и версионность вводить и проверять. Оно точно надо?

С Уважением,
Георгий

[mazzy]

Цитата:

Сообщение от George Nordic

а насколько нужно ее часто реплицировать? Это и брокера убьет нафик. Плюс возможны будут варианты, когда изменение со старой себестоимостью придет позже сообщения с новой себестоимостью - не факт что брокер будет успевать доставить все по очереди(!). Значит, еще и версионность вводить и проверять. Оно точно надо?

воооот! прекрасные вопросы.
а какие есть варианты решений?

как технарь со знанием, можешь выделить важные параметры и граничные значения и как они влияют?

повторю, вопрос, в котором я постарался зафиксировать действительно важные на мой взгляд параметры:

ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?

готов послушать для вариантов, где используется не WCF. но все остальные слова остаются в вопросе.

готов принять вводные характерные для аксапты. например, это точно не "горячее копирование". например, нормальная скорость 1 изменение в секунду. например, размер элемента в коллекции до 8кб, а число элементов измеряется скорее сотнями тысяч, но никак не сотнями миллионов. и другие характерные для аксапты вводные.

[George Nordic]

Цитата:

Сообщение от mazzy

1К изменений в секунду.

Это кто-то погорячился. Я такие скорости только в большом телекоме видел. Поправь, плиз.

С Уважением,
Георгий

[mazzy]

Цитата:

Сообщение от George Nordic

Это кто-то погорячился. Я такие скорости только в большом телекоме видел. Поправь, плиз.

С Уважением,
Георгий

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

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

[George Nordic]

Давай немного переформулирую. В основном затык происходит не на стороне брокера или CDC, а на стадии обработки принятого сообщения.

Давай уточню сначала по CDC: из БД 2009 в БД 2012 скорость репликации будет очень высокой, если RecID будет выделяться самой БД. Но если Rec будет выделять AOS, то он станет бутылочным горлышком, а если еще и номерные серии надо заполнять...

То же самое и с брокерами. В принципе, за счет распараллеливания и оптимизации размера пакетов - то хоть 1К в секунду, хоть миллион. Но с какой скоростью будет его разбирать пакетный сервер если мы говорим по DAX? И параллельно запускать обработку вряд ли получится, так как есть вероятность что сообщение с новой себестоимостью в данном случае будет обработано до сообщения со старой себестоимостью.

Абстрагируясь от DAX, то если мы говорим про надежную доставку, то это - запись на диск. Таким образом надо смотреть на пропускную способность сети и скорость записи на диск. Например, для AWS это 40 000 IOPS составляет при пакете в 16 КБ и 20 000 IOPS при 32 КБ

Таким образом, я не вижу проблемы в передаче 100500 сообщений. Я вижу проблему в их парсинге, если будет задействованы механизмы DAX - тот же АОS, которые будут заполнять служебные поля. Если доверить эту задачу БД, а служебные поля заполнять автоматом по некому шаблону механизмами БД, то данная проблема снимается. Но вряд ли этим снимается проблема последовательной обработки сообщений.

С Уважением,
Георгий

[Vadik]

Bingo!

[mazzy]

Цитата:

Сообщение от George Nordic

Давай немного переформулирую. В основном затык происходит не на стороне брокера или CDC, а на стадии обработки принятого сообщения.
...
Я вижу проблему в их парсинге, если будет задействованы механизмы DAX - тот же АОS, которые будут заполнять служебные поля.

даже не столько в парсинге, сколько в валидации входащих данных.

т.е. ты тоже как и Vadik передать/отправить сводишь к "запросить" и к принимающей стороне.

все понимаю про принимающую сторону.
поэтому в вопросе сформулировано о передать/отправить.

принимающая сторона в части парсинга и валидации входящих данных - отдельный вопрос.

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

Цитата:

Сообщение от George Nordic

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

Я уже сказал, пусть будет 1 запись в секунду. Пусть будет 10 записей в секунду.
По-моему, не принципиально для заданного вопроса.

[George Nordic]

Цитата:

Сообщение от mazzy

т.е. ты тоже как и Vadik передать/отправить сводишь к "запросить" и к принимающей стороне.

Потому что задачу надо решать комплексно. Смысл в посылке 100500 сообщений, если они не будут обработаны и будут тупо писаться в буфер на диске?

Извини, но твой вопрос

Цитата:

Сообщение от mazzy

как правильно передавать/отправлять много элементов коллекции в Аксапте, где нет встроенных стримов.

Выглядит как "как вкорячить 1000-лошадный двигатель на шаху?". Мы с Вадимом пытаемся объяснять про тормозную систему и управляемость, в ответ слышим "да ладно тормоза, главное разогнаться!". Результат как бы немного предсказуем.

С Уважением,
Георгий

[mazzy]

можно я еще раз повторю свое первое предложение в первом сообщении этой ветки?

Цитата:

Сообщение от mazzy

Сразу скажу, что решение есть, конечно.
Хотелось бы обсудить вопрос как лучше и как правильно

Цитата:

Сообщение от George Nordic

Потому что задачу надо решать комплексно. Смысл в посылке 100500 сообщений, если они не будут обработаны и будут тупо писаться в буфер на диске?

ты это мне говоришь?

===============================
итак,

всё ещё надеюсь услышать мнения по вопросу:

ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?

дополнительные вводные, которые были уточнены по ходу ветки и в личной переписке:
* "передать" в смысле "отправить"
* в аксапте есть recId и нумераторы
* в аксапте нет встроенной поддержки потоков (stream).
* аксапта 2009 работает на .net 3.5
* аксапта 2012 работает на .net 4.0 (не 4.5)
* размер элемента коллекции в Аксапте до 8Кб
* размер коллекции до 100500 элементов, но вряд ли больше 2^32
* вместо WCF можно обсуждать любой другой брокер/транспорт
* предполагаем, что middlware отсутствует. но мы можем сделать любой
* для простоты предполагаем, что все компоненты под нашим контролем и вопросы безопасности решены

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

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

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

[CDR]

Цитата:

Сообщение от mazzy

ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?

Я так полагаю, вопрос "ax2012,ax2009: как правильно передать 1 элемент через WCF?" уже успешно решен?

[gl00mie]

Цитата:

Сообщение от mazzy

всё ещё надеюсь услышать мнения по вопросу:
ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?

По-моему, вся тема - про то, что ax2012,ax2009: правильно передать 100500 элементов коллекции НЕ через WCF

Цитата:

Сообщение от mazzy

дополнительные вводные, которые были уточнены по ходу ветки и в личной переписке:
* "передать" в смысле "отправить"
* в аксапте есть recId и нумераторы
* в аксапте нет встроенной поддержки потоков (stream).
* аксапта 2009 работает на .net 3.5
* аксапта 2012 работает на .net 4.0 (не 4.5)
* размер элемента коллекции в Аксапте до 8Кб
* размер коллекции до 100500 элементов, но вряд ли больше 2^32

Мне лично думается, что как только возникает 100500 элементов для передачи, интеграция должна становиться асинхронной, а связь ax2012 и ax2009 через WCF как-то не очень ложится на идею асинхронного обмена (без собственных dll, "и чтобы эти собственные dll'ки работали в адресном пространстве аксапты"). Это вроде само собой разумеется уже: если требуется обрабатывать в системе много документов, то надо писать пакетную обработку с распараллеливанием. Если требуется передавать между системами большие объемы данных, то надо делать асинхронный обмен.
На тему проектирования интеграций есть хорошая статья у Дениса Трунина, где он предлагает для начала определиться с такими моментами:

• Топология решения интеграции
• Требования для потока данных
• Анализ свойств потока данных
• Определение качества обслуживания (QoS)
• Производительность
• Доступность и надежность
• Безопасность
• Масштабируемость
• Логирование и м... "неподдельность" (nonrepudiation)

И уже по совокупности требований будет ясно, WCF это окажется или не WCF...

Цитата:

Сообщение от mazzy

* вместо WCF можно обсуждать любой другой брокер/транспорт
* предполагаем, что middlware отсутствует. но мы можем сделать любой
* для простоты предполагаем, что все компоненты под нашим контролем и вопросы безопасности решены

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

А что 100500 элементов будут парситься/валидироваться/обрабатываться в один поток слишком медленно - не беспокоит? А как при распараллеливании приемки данных не забить все доступные потоки на пакетном сервере/серверах (привет от закрытия склада), тоже не беспокоит?

Цитата:

Сообщение от mazzy

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

Брокер/транспорт при асинхронном обмене даст принимающей стороне возможность обрабатывать сообщения тогда и в таком темпе, в каком ей комфортно, не просаживая другие поддерживаемые бизнес-процессы. А стороне-отправителю даст возможность не ждать ответа и не отправлять все 100500 элементов, скажем, одним куском повторно, если у принимающей стороны что-то не заладилось.
В обсуждении много говорилось про очереди, шины данных и т.п. По-моему, если нужно перебрасывать между двумя системами такие объемы данных, стоит посмотреть в сторону какого-нить RabbitMQ хотя бы. Разбивать ли коллекцию из 100500 элементов на блоки при передаче? Решать, конечно, на местах, но я бы тут вспомнил про то, что в ядре, начиная с AX2009, есть ограничение на размер буфера под значимые типы (тот же string), которое по умолчанию, кажется, равно 1Мб - см. Падает клиент при прикреплении файла. Так что если утоптать 100500 элементов в один большой XML/JSON, то на принимающей стороне с ним может быть непросто работать. Я бы в связи с этим постарался разбивать передаваемые данные на блоки меньше 1Мб каждый.

Цитата:

Сообщение от CDR

Я так полагаю, вопрос "ax2012,ax2009: как правильно передать 1 элемент через WCF?" уже успешно решен?

Кажется, у Макконнелла в Code Complete было:

Цитата:

Для построения метровой башни требуется твердая рука, ровная поверхность и 10 пивных банок, для башни же в 100 раз более высокой недостаточно иметь в 100 раз больше пивных банок. Такой проект требует совершенно иного планирования и конструирования.

[mazzy]

Цитата:

Сообщение от gl00mie

...тоже не беспокоит?

конечно же беспокоит.
поэтому и была создана тема.

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

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

Цитата:

Сообщение от gl00mie

...при асинхронном обмене

[mazzy]

Цитата:

Сообщение от gl00mie

Разбивать ли коллекцию из 100500 элементов на блоки при передаче? Решать, конечно, на местах

собственно тема КАК правильно решить на местах?

Цитата:

Сообщение от gl00mie

но я бы тут вспомнил про то, что в ядре, начиная с AX2009, есть ограничение на

а с чего ты решил, что об этом кто-то забыл?

Цитата:

Сообщение от gl00mie

и не отправлять все 100500 элементов, скажем, одним куском повторно

а кто-то говорил "одним куском"?!

[mazzy]

Цитата:

Сообщение от CDR

Я так полагаю, вопрос "ax2012,ax2009: как правильно передать 1 элемент через WCF?" уже успешно решен?

когда ж вы ТЗ научитесь читать?

Цитата:

Сообщение от mazzy

Сразу скажу, что решение есть, конечно.
Хотелось бы обсудить вопрос как лучше и как правильно

[DSPIC]

Цитата:

Сообщение от mazzy

Сразу скажу, что решение есть, конечно.

Ну так и на чем в итоге остановились?

[mazzy]

Цитата:

Сообщение от DSPIC

Ну так и на чем в итоге остановились?

пока разбиваем на чанки с фиксированным числом элементов.
и написан код для обслуживания этих чанков.

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

но "остановились" - это неправильное слово.
скорее, приняли в качестве первой версии.