В nifi usgae процессора Evaluate jsonpath это повлияет на производительность из-за создания атрибутов

Question

Я пытаюсь интегрировать API REST nifi с моим приложением. Таким образом, сопоставляя ввод и вывод из моего приложения, я пытаюсь вызвать API REST nifi для создания потока. Поэтому в моем случае использования большую часть времени я извлекаю значения JSON и применяю языки выражений.

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

Правильный ли это подход, потому что для манипуляции с JSON в JSON с 30 ключами это самый простой способ, и, поскольку я пытаюсь интегрировать API-интерфейсы REST nifi с моим приложением, я не могу динамически генерировать логику преобразования JOLT на основе сопоставления пользователя.

Таким образом, в этом случае использование оценки процессора JSONpath создает какие-либо проблемы с производительностью примерно для 50 вариантов использования с другой логикой преобразования, поскольку, как я видел в документации, использование атрибутов создает проблемы с производительностью (в отношении памяти).

Answer 1

Ваша проблема с наличием слишком большого количества атрибутов в памяти не должна быть проблемой здесь; наличие 30 атрибутов на файл потока выше, чем обычно, но если все эти строки находятся в диапазоне от 0 до ~ 100-200 символов, влияние должно быть минимальным. Если вы начнете пытаться извлекать данные в КБ данных из содержимого потокового файла в атрибуты каждого потокового файла, вы увидите увеличение использования кучи, но инфраструктура все еще сможет справиться с этим, пока не достигнете очень высокой пропускной способности (1000 потоковых файлов в секунду). на товарном оборудовании как у современного ноутбука).

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

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