處理固定寬度文件的高效模式

我有一種情況，我需要讀取接近100000個邏輯記錄的平面文件。每個邏輯記錄由n×128個字符部分組成。即類型A：3×128，類型B：4-5×128等，其中最大可能的n是6.處理固定寬度文件的高效模式

應用程序必須讀取文件並處理記錄。問題是'n'只能在讀取每個nx128分區的前52個字符時才能確定。

請問您能否提供任何可以重複使用的設計模板或任何有效的算法來執行此操作？

注意：1.性能是一個重要標準，因爲應用程序需要每天處理數千個文件。 2.數據不是按行分隔的。它是一個很長的字符串，如圖案

來源

2011-06-24 nobody

你需要有人爲你做這項工作嗎？ – Marcelo

同上。讀取記錄並處理它們...我沒有看到問題 – dagnelies

問題是我無法讀取固定寬度，請立即說出nX128。首先，我需要閱讀52個字符。然後確定'n'是什麼，然後讀取nX128個字符。這對我來說似乎是一個非常糟糕的設計。 – nobody

你可以通過一個主工人（或主從）模式，其中主線程將負責讀取數據的前52個字符以確定記錄的長度。然後，主人可以將實際讀取和處理記錄的工作推遲到工作者線程，並再次轉到下一個記錄以僅讀取前52個字符。每個工作人員將負責（重新）打開文件並處理特定範圍的字符;工作人員需要提供這些信息。

，因爲我還沒有看到文件的結構，我只能發佈一些可能的限制或擔憂的實施者思考：

一個有效的和高性能的實施將依靠能力爲工作線程提供文件指針和工作人員應處理的數據長度。簡而言之，工作者線程應該以隨機訪問模式實際讀取文件，而不是讓主人讀取（這是串行的）。如果你不能執行隨機訪問，你可以做很多事情來優化主人模式。
不建議產生新的工作線程。使用線程池。這也意味着您可以根據池的大小限制打開的文件描述符的數量。
排隊處理字符範圍的進一步請求，以防萬一池被耗盡。這樣，主人可以繼續工作，直到讀完最後一個記錄。
跨記錄的依賴關係需要您序列化處理記錄。如果每條記錄都可以在自己的線程上處理，而不需要其他線程的結果可用，那麼在採用這種方法時不應該遇到任何困難。

來源

2011-06-24 17:17:37

非常感謝這個想法。這是文件應用程序的描述必須閱讀[鏈接]（http://www.six-interbank-clearing.com/dl_tkicch_dta.pdf）。摘自第16頁的pdf。 – nobody

我只讀過該文檔頭結構的描述，看起來您可能能夠使用主工模式。但是，我不知道幾個列的上下文語義，比如'output sequence number'。另外，我不確定您正在處理的處理的性質。由於這是一種清算網絡文件格式，因此我會假設您還必須準備一個輸出文件或類似的文件確認處理。您還必須考慮準備該文件的機制。 –

是的維尼。主工人模式看起來對我很有希望。非常感謝你的努力。 – nobody

除非你可以改變格式，你必須解決它。

您可以爲每個文件創建一個索引，但你必須一次讀它來建立索引（但它會節省不必做這一次以上）

來源

2011-06-24 17:08:04

處理固定寬度文件的高效模式

回答

相關問題