大數(shù)據(jù)量下的記錄統(tǒng)計問題

hbxfsz18

項目簡介：

       一個參數(shù)文件裝載的項目，參數(shù)最初寫在文件中，通過多線程方式讀取記錄后，更新到數(shù)據(jù)庫中，記錄存在三種操作類型：I(Insert), U(Update), D(Delete).存儲參數(shù)的表較大(記錄上億)

       參數(shù)文件的更新有兩種渠道：一種是通過讀取文件方式，另一種是通過界面。文件方式的數(shù)據(jù)量較大(可達到百萬級)，且修改的頻率較高(可能一天有好幾次大文件的更新)，界面方式修改的數(shù)據(jù)量較小(通常100以下)，且頻率相對讀文件方式低。兩種更新方式均不可預知更新時間，次數(shù)，更新記錄數(shù)等

       現(xiàn)需求要求：能盡可能實時的統(tǒng)計出參數(shù)表中按某個字段分類下的I,U,D的記錄數(shù)量，例如：如果表中有A,B,C三個用戶的記錄，那么現(xiàn)在就要統(tǒng)計出A,B,C三個用戶的I,U,D記錄分別是多少。
       另外，由于表中的數(shù)據(jù)還要供聯(lián)機交易使用，所以這里的統(tǒng)計必須控制對系統(tǒng)性能的影響，這個是首要注意的問題。

       綜合以上，目前考慮的設計為：每天更新一次統(tǒng)計信息，并且將不同的用戶的統(tǒng)計任務從時間上分開，比如1點統(tǒng)計A用戶的，2點統(tǒng)計B用戶的。但這樣的缺陷在于，統(tǒng)計信息就只能精確到前一天。

       另外，考慮過將表中數(shù)據(jù)導入另一個庫，或者將記錄導出到文件，然后再從文件做統(tǒng)計，前者對系統(tǒng)架構上有影響，后者考慮效率可能不高。

這個地方的設計，需要考慮四點：
      1. 對系統(tǒng)性能的影響   
      2. 對現(xiàn)有系統(tǒng)的改造
      3. 統(tǒng)計結果的準確性
      4. 統(tǒng)計機構的實時性

      按照重要程度來排序的話，1 > 2 > 3,4
      其中，第一點是必須滿足的，對系統(tǒng)性能的影響必須盡可能小，不能影響聯(lián)機交易(聯(lián)機交易對表的操作只有查詢)

      第二點，減少現(xiàn)有系統(tǒng)改造的話，就要從數(shù)據(jù)庫，參數(shù)文件這方面入手了，盡量不修改現(xiàn)有代碼(相關的表有兩個：1. 記錄該參數(shù)是表   2. 記錄每個參數(shù)文件信息的表)

      第三點，統(tǒng)計結果的準確性，因為記錄數(shù)量是千萬到億級的，可以允許一定數(shù)量級的誤差(目前的需求，誤差不超過1萬可以接受)

      第四點，統(tǒng)計結果的實時性，按照現(xiàn)有的設計思路，結果僅每天統(tǒng)計一次，不太能滿足需求。

      本來，直接在程序裝參數(shù)過程中同時更新統(tǒng)計信息應該是最佳方案，對系統(tǒng)性能近乎沒有影響，實時性和準確性也能保證，但是卻對現(xiàn)有系統(tǒng)有不小的改動，因而未考慮。

      目前倒是可以通過讀參數(shù)文件，預判出參數(shù)文件中記錄的數(shù)量和修改的值(I,U,D)，但是無法知道確切的值(I可能插入重復記錄，會丟棄，不能記入統(tǒng)計；U可能更新不存在的記錄，則操作會變成Insert；D可能刪除不存在記錄,此條記錄是不能記入統(tǒng)計的；還有可能出現(xiàn)的數(shù)據(jù)庫操作失敗，導致相應的操作無法成功)
      
      通過預判文件的數(shù)量級，可以實時判定出哪些用戶的記錄數(shù)發(fā)生了較大的改變，需要重新更新統(tǒng)計信息，以提高統(tǒng)計信息的實時性(預判會有誤差，但當參數(shù)文件達到一定數(shù)量級時，判定出的更新影響結果也會相對可靠)，但下一步如何在不影響性能的情況下更新相應用戶的統(tǒng)計信息？  請各位指教