堅持處理記錄

我有一個c＃進程，對使用TPL並行處理的隊列工作。處理完每條記錄後，我希望爲每個處理過的記錄ID建立一個物理記錄，以便如果處理失敗或中斷，我可以確保不再處理該記錄。 記錄只能處理一次是非常重要的。堅持處理記錄

我試圖序列化的記錄ID，以一個簡單的文本文件，並以一個SQLite表。在這兩種情況下，保存這些小記錄ID（Guid's）的時間佔記錄本身總處理時間的50％。我甚至嘗試過使用一個開放的Sqlite連接和一個parameritized插入查詢來做插入操作，所以我沒有打開/關閉數據庫文件，它沒有更好的。

我的問題是，我如何維護一個Guid（可能是1000-2000）的列表，以便如果我的進程死了，我會讓他們保存，這樣我就可以從中斷？我願意嘗試任何事情，只要速度很快，並且如果服務器重新啓動或進程被終止，它仍然會在那裏。

任何想法？

來源

2012-12-31 powlette

它不能花時間寫入文件和SqlLite。你能分享你的代碼嗎？正確寫入時（使用緩衝流）寫入文件速度非常快。另外，你不需要將它寫入TEXT文件本身，你可以分享代碼嗎？另外，我的記錄器每秒發出50,000條消息到磁盤（從測試線束）到1-2％的CPU到磁盤。寫入磁盤比任何SQL（甚至SQLLite）都快。 –

使用SQL Server如何？ – user1610015

我的第一次嘗試是打開一個文件進行追加，寫入一行並關閉它，但是所有等待訪問該代碼塊的線程都放慢了速度。我認爲追加，寫入，關閉週期的開放太慢了。有沒有更快的方法，以確保緩衝區在沖洗過程中死亡？ – powlette

凡是是足夠持久生存重啓將必須遲早（優選越快）寫入到磁盤。

這意味着你已經非常列舉你的選擇。

您必須要提出的下一個問題是，驗證記錄是否已經處理以及最終用戶無意中刪除跟蹤機制的危險程度是多少。

如果你只是將信息寫入到一個文本文件，它應該是一個快寫，而是一個緩慢的讀取（除非你緩存中的信息）和可能性，用戶將刪除該文件是相當高的。

如果你使用任何類型的數據庫，寫應該還是相當快和檢索應該比文本文件和可能性的更快，用戶將刪除存儲機制要低得多。

基於這些因素，我會強烈推薦某種數據庫。我將模擬（或研究）一些不同的數據庫以獲得性能，以查看哪些數據庫能夠提供最佳性價比，其中應包括實施，部署和維護的成本。

來源

2012-12-31 01:59:00

堅持處理記錄

回答

相關問題