批處理流文件進入MergeContent

Question

我使用MergeContent按以下方式「批量」處理來自多個ExecuteSQL的傳入響應。在合併內容處理器中，我將「最小條目數」設置爲1000，「最大條件期限」設置爲30秒。然後我有一個相關屬性名稱，用於分揀傳入的FlowFiles。這似乎按我的預期工作，但我的問題有兩個：

答：這是一個明智的方法，還是有更好/更有效的方法來做到這一點？也許組合的ListFile/GetFile/MergeContent等...

B.是否存在性能/可伸縮性問題，具有「較大」數量的最小入口數量？

我的最終目標是嘗試將來自ExecuteSQL命令的許多結果合併到單個文件中，並由其相關屬性名稱進行歸檔。

Answer 1

你的方法似乎很紮實。 SplitContent和MergeContent處理器旨在處理大量的流文件（請記住流文件內容實際上並未在堆空間中傳遞，而是存儲在內容存儲庫中，並且流文件充當引用指針）。在很多情況下，我們看到用戶「堆棧」這些處理器 - 即讀取一百萬條記錄的文件，一個初始的SplitContent處理器分裂成每個包含10,000條記錄的流文件，然後第二秒將這些流文件拆分爲單個記錄，而不是去從一個單一的操作100萬到1個。這提高了性能並減少了OutOfMemoryException的可能性。

同樣，您可以使用第二個MergeContent處理器將包含1,000個條目的流文件合併到單個流文件中的較大集合中。這個決定取決於你當前的吞吐量 - 30秒裝箱和1000個條目的結合是否讓你始終擁有1,000個條目的流文件，還是隻有幾百個？您可以評估流程文件的數據來源以確定這一點，並且您可以設置並行流程以基本上A/B測試您的配置。