我正在尝试将nifi RESTAPI与我的应用程序集成。因此，通过映射应用程序的输入和输出，我尝试调用nifi REST api来创建流。因此，在我的用例中，大多数时候我会提取JSON值并应用表达式语言。
因此，为了简化我正在使用的所有用例，评估JSONpath处理器，使用jsonpath获取所有属性，并在提取处理器中应用表达式语言功能。下面是关于这一点的流程图。
这是正确的方法吗？因为对于JSON来说，JSON具有30个键的操作这是最简单的方法，而且当我试图将nifi RESTAPI与我的应用程序集成时，我无法根据用户映射动态生成JOLT转换逻辑。
因此，在这种情况下，评估JSONpath处理器的使用是否会为大约50个具有不同转换逻辑的用例带来任何性能问题，因为正如我在留档属性使用中看到的那样，会产生性能（关于内存）问题。
你对内存中属性过多的担忧在这里不应该是一个问题；每个流文件有30个属性比平时高，但是如果这些都是0-~100-200个字符之间的字符串，影响应该很小。如果你开始尝试从流文件内容中提取KB的数据到每个流文件的属性中，你会看到堆使用率增加，但是框架应该仍然能够处理这个问题，直到你达到非常高的吞吐量（像现代笔记本电脑这样的商品硬件上每秒1000个流文件）。
您可能需要研究Replace eTextWellMaps，因为该处理器可以从定义文件加载并使用单个处理器处理许多替换操作。
拥有具有不同配置值的相同流进程的多个副本通常是一种流设计“气味”（偶尔数据库交互除外）。相反，看看是否有一种方法可以泛化该过程并使用变量填充每个流文件的相关值（来自传入的流文件属性、变量注册表、环境变量等）。
