共計 1379 個字符，預計需要花費 4 分鐘才能閱讀完成。

這篇“服務器數據沉淀的方案分析”文章的知識點大部分人都不太理解，所以丸趣 TV 小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“服務器數據沉淀的方案分析”文章吧。

從數據層面來理解，數據可以分為幾個維度，比如流水型數據，狀態型數據庫，配置型數據。流水型數據的依賴最低，基本就是時間維度的擴展，所以從數據的安全角度來說，如果丟數據對業務的影響還是有限的，配置型數據是數據字典級別的，影響范圍更是小很多。關鍵的就是狀態型數據，這是非常核心的，因為只是標識狀態的變化，如果換做一個場景，比如是金額，那這個維度的影響是很大的。

從數據架構的角度來說，盡可能希望把一些狀態型數據的變化，通過流水數據的方式來做一個歷史沉淀，我們暫且成為歷史數據吧。

比如 更新狀態數據，余額為 200

Account_id, balance,effective_date, expire_date, status

100 100 20171004010100 20181104010200 1

可以改造為：

Account_id, balance,effective_date, expire_date, status

100 100 20171004010100 20171104010200 0 — update 語句

100 200 20171104010200 20181104010200 1 — insert 語句

所以顯而易見的，一個 update 被改造為了兩條語句，從數據生命周期來看，確實有了一定的保障，這也是我們需要和開發同學強調的一種設計方式。

然后我們看一下這種歷史數據的處理方案和想法。

一般來說，從設計的角度，盡可能是希望這樣來處理歷史數據的變化，即從程序層面來解讀這個數據的變化情況，可以包裝在一個事務里，也可以根據需求來拆分成為異步的方式。當然這種方式是一種看起來很自然的方式，其實也是一種相對來說最理想的方式，從我刻意來畫的圖來看，是強應用型的。

如果換一個角度來說，對于應用來說，歷史數據的生成對于他們是透明的，即他們不需要刻意關注這個邏輯，那么這個邏輯就會下沉到數據庫層面，所以我畫的圖中，HIST 的部分就會放大，這個邏輯如果在數據庫層面來處理，一種自然的方式就是存儲過程，當然會對應有一系列的邏輯處理，比如一類業務需要這些歷史數據的生成方式，其他類似的業務也是這種思路，那么就需要有一種更加通用的方式，其實從數據庫層面來說，這種算是重系統層面的實現，因為數據庫層面如果綁定了這個邏輯，那么如果來做擴展就是一個難題了。

還有一種方式，可能折衷一些，即程序可能下沉到數據處理層，數據庫處理層不用刻意去關系數據的意義，數據層可以做數據的寫入和流轉，可以通過程序層來包裝事務來生成歷史數據或者是透明的通過 OLTP 數據生成歷史數據，但是關鍵的一點是，歷史數據和 OLTP 的數據是放在一起的，當然這個表的數據會放大，所以我們需要做一種偏離線的數據歸檔，比如保留近 7 天的數據即可。而歷史數據可能保留有幾個月甚至幾年，這樣一來歷史的數據倒是可以實現分布式存儲，可能實際的意義和成本需要做平衡。

以上就是關于“服務器數據沉淀的方案分析”這篇文章的內容，相信大家都有了一定的了解，希望丸趣 TV 小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注丸趣 TV 行業資訊頻道。