我正在以下列方式使用MergeContent来“批量”来自多个ExecuteSQL的传入响应。在MergeContent Processor中，我将最小条目数设置为1000，将最大Bin时间设置为30秒。然后我有一个关联属性名称，用于存储传入的FlowFiles。这看起来像我期望的那样有效，但我的问题有两个方面：
一个。这是一种明智的方法还是有更好/更有效的方法来做到这一点？也许是ListFile / GetFile / MergeContent等的组合......
B中。是否存在“最大”条目数“更大”的性能/可扩展性问题？
我的最终目标是尝试将来自ExecuteSQL命令的尽可能多的结果合并到一个文件中，并通过其相关属性名称进行分类。
答案 0 :(得分：6)
你的方法似乎很扎实。 SplitContent和MergeContent处理器旨在处理大量的流文件（请记住，流文件内容实际上并未在堆空间中传递到系统中，而是存储在内容存储库中，并且流文件执行作为参考指针）。在许多情况下，我们看到用户“堆叠”这些处理器 - 即读取包含100万条记录的文件，初始SplitContent处理器分成每个包含10,000条记录的流文件，然后第二条将这些流文件拆分为单独的记录而不是在一次操作中从100万变为1。这样可以提高性能并降低OutOfMemoryException的可能性。
类似地，您可以使用第二个MergeContent处理器将包含1,000个条目的流文件聚合到单个流文件中的更大集合中。决定取决于您当前的吞吐量 - 30秒分箱和1,000个条目的组合是否可以让您始终拥有包含1,000个条目的流量文件，或者它们只能获得几百个？您可以评估流文件的数据来源以确定这一点，并且您可以将并行流设置为基本上A / B测试您的配置。