服務器數(shù)據(jù)沉淀的方案分析

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

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

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

比如 更新狀態(tài)數(shù)據(jù)，余額為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被改造為了兩條語句，從數(shù)據(jù)生命周期來看，確實有了一定的保障，這也是我們需要和開發(fā)同學強調(diào)的一種設(shè)計方式。

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

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

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

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

以上就是關(guān)于“服務器數(shù)據(jù)沉淀的方案分析”這篇文章的內(nèi)容，相信大家都有了一定的了解，希望小編分享的內(nèi)容對大家有幫助，若想了解更多相關(guān)的知識內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道。