大數(shù)據(jù)量下的存儲設計模式探索

引言

現(xiàn)實世界商務競爭越演越烈，出現(xiàn)更多的細分市場、深度營銷和定制功能，這導致各種商務應用的用戶數(shù)和業(yè)務復雜度同步增加。反映到數(shù)據(jù)庫里，就是表的數(shù)量和數(shù)據(jù)量日益增長，數(shù)據(jù)庫響應速度日益緩慢。

為什么一個功能好的產品，往往上線后就出現(xiàn)性能問題，不得不反復回爐修改？為什么一到業(yè)務高峰期，系統(tǒng)就慢的動彈不得，只能關閉部分業(yè)務保障關鍵業(yè)務？數(shù)據(jù)量從十萬到百萬，從百萬到千萬，從千萬到上億，從億再向兆跨越，如何保障程序能夠經受住大數(shù)據(jù)量的考驗？這都是我們面臨的真實現(xiàn)狀，也是大家反復在思考的問題。

《道德經》上說：“有道無術,術尚可求,有術無道,止于術。”眾人把目光集中在系統(tǒng)架構、查詢算法、數(shù)據(jù)庫軟件的底層原理等等“術”上，卻忽視了深刻理解數(shù)據(jù)這條光明大“道”。數(shù)據(jù)從哪里來？要到哪里去？數(shù)據(jù)用來讀還是寫？數(shù)據(jù)與數(shù)據(jù)之間有什么樣的關系？數(shù)據(jù)的增長速度如何控制？最有價值的數(shù)據(jù)是什么？數(shù)據(jù)什么時候可以丟棄？假如不能回答這一長串問題，如果不是以這一長串問題的答案為程序設計的出發(fā)點，代碼如何能經受大數(shù)據(jù)量的考驗？

在數(shù)據(jù)的采集、計算、展現(xiàn)和存儲這一設計鏈條中，開發(fā)者通常負責設計關系型數(shù)據(jù)模型，編寫程序計算和展現(xiàn)數(shù)據(jù)，數(shù)據(jù)庫管理員負責數(shù)據(jù)文件存放位置、表空間存儲參數(shù)等的架構設計。但是，數(shù)據(jù)庫管理員往往不了解業(yè)務，不了解數(shù)據(jù)的特點，數(shù)據(jù)存儲設計表現(xiàn)為千“表”一律。

數(shù)據(jù)存儲設計模式是根據(jù)數(shù)據(jù)的真正特點，仔細分析數(shù)據(jù)流向、數(shù)據(jù)訪問特點、數(shù)據(jù)量、數(shù)據(jù)增長量和數(shù)據(jù)生命周期，對數(shù)據(jù)進行分類，然后根據(jù)不同類型的數(shù)據(jù)設計不同的存儲策略。正確的應用數(shù)據(jù)存儲設計模式，可以幾倍，甚至幾十倍的提高數(shù)據(jù)訪問效率。

大數(shù)據(jù)量下的數(shù)據(jù)特點

全球最大數(shù)據(jù)庫的數(shù)據(jù)量已經先后越過了MB量級、GB量級和TB量級，站到了PB量級的門口。在龐大的數(shù)據(jù)量面前，對數(shù)據(jù)進行分類顯得尤為重要。人們對數(shù)據(jù)感興趣的時間是不一樣的，大量的數(shù)據(jù)進入數(shù)據(jù)庫后，經過計算、聚集和轉換，僅有少量的活躍數(shù)據(jù)需要長期保留在數(shù)據(jù)庫中，剩下的數(shù)據(jù)只有備查的價值，可以暫時存儲在數(shù)據(jù)庫中或者離線備份，等到休眠數(shù)據(jù)完全沒有價值后直接刪除。

需要長期保留在數(shù)據(jù)庫的活躍數(shù)據(jù)可以稱之為核心數(shù)據(jù)，它是整個商業(yè)活動中最有價值的數(shù)據(jù)，需要長期甚至永久的保留。程序完成處理后只需要備查的休眠數(shù)據(jù)可以稱之為過程數(shù)據(jù)，是伴隨核心數(shù)據(jù)流動所產生的數(shù)據(jù)，它的存在周期視商業(yè)活動的重要性而定。

數(shù)據(jù)的分類有利于把資源聚焦于有價值的數(shù)據(jù)，我們可以通過以下幾個方面識別核心數(shù)據(jù)和過程數(shù)據(jù)：

識別項

核心數(shù)據(jù)

過程數(shù)據(jù)

數(shù)據(jù)流向

幾乎不流動

按工作流的方式運動

數(shù)據(jù)的訪問特點

主要讀，多半是關聯(lián)查詢

主要寫，更新和刪除涉及到查詢

數(shù)據(jù)量

大

非常大

數(shù)據(jù)的增長量

增長緩慢或者完全不增長

增長迅速，甚至是爆發(fā)性的

數(shù)據(jù)生命周期

長，甚至永久的保留

短，幾天到幾個月不等

表類型

表說明

核心表

數(shù)據(jù)生命周期長，讀比寫的訪問頻率高，數(shù)據(jù)增長慢

恒數(shù)表

數(shù)據(jù)量小，總是讀，很少寫

遞增表

數(shù)據(jù)量大，經常讀，很少寫。某些情況會頻繁寫。

在大數(shù)據(jù)量環(huán)境下，數(shù)據(jù)庫服務器的資源是昂貴的，混合核心數(shù)據(jù)和過程數(shù)據(jù)的后果就是資源被不重要的數(shù)據(jù)占用，被不必要的進程占用，導致性能緩慢和堵塞。常見的誤解數(shù)據(jù)特點的現(xiàn)象包括：

核心數(shù)據(jù)和過程數(shù)據(jù)以不同字段的形式在同一條記錄里存放

核心數(shù)據(jù)和過程數(shù)據(jù)以不同記錄的形式在同一張表里存放

把不同隊列的過程數(shù)據(jù)在同一張表里存放

過程數(shù)據(jù)沒有合適的退出機制，長期保留在數(shù)據(jù)庫中

數(shù)據(jù)表的分類

在一個大數(shù)據(jù)量環(huán)境中，表的數(shù)量往往達到數(shù)千張。根據(jù)核心數(shù)據(jù)和過程數(shù)據(jù)的不同特點，可以將表大致分為2個大類，4個子類。

核心表及子類的明細定義如下：

表類型

表說明

核心表

數(shù)據(jù)生命周期長，讀比寫的訪問頻率高，數(shù)據(jù)增長慢

恒數(shù)表

數(shù)據(jù)量小，總是讀，很少寫

遞增表

數(shù)據(jù)量大，經常讀，很少寫。某些情況會頻繁寫。

在核心表的關系型數(shù)據(jù)模型設計階段，有以下原則需要遵守：

務必要尊重范式，即確保原子性，檢查對鍵的依賴性，檢查屬性獨立性等三個原則。

嚴格控制關鍵遞增表的字段個數(shù)和字段長度。

重要的遞增表的屬性一旦定義，不允許隨意添加字段。后續(xù)業(yè)務升級最好是增加新的遞增表。

如果遞增表總是需要做范圍查詢，應重新審視關系型模型。

過程表及子類的明細定義如下：

表類型

表說明

過程表

數(shù)據(jù)生命周期短，寫比讀的訪問頻率高，數(shù)據(jù)增長快

流水表

數(shù)據(jù)量大，經常寫，很少讀。只插不改，定期刪。

狀態(tài)表

數(shù)據(jù)量大，經常寫，經常讀。邊插邊改邊刪。

在過程表的關系型數(shù)據(jù)模型設計階段，有以下原則需要遵守：

設計明顯的代表數(shù)據(jù)生命周期終止的字段

從增刪改的代價來考慮，插入代價最小，修改需檢索數(shù)據(jù)，刪除最為昂貴，可考慮多設計流水表，少設計狀態(tài)表。

數(shù)據(jù)表的分類有利于圍繞不同類型的數(shù)據(jù)進行不同的存儲模式設計。我們可以通過數(shù)據(jù)流向、數(shù)據(jù)訪問特點、數(shù)據(jù)量、數(shù)據(jù)增長量和數(shù)據(jù)生命周期等識別四種表類型：

識別項

恒數(shù)表

遞增表

流水表

狀態(tài)表

數(shù)據(jù)流向

幾乎不流動

數(shù)據(jù)很少流動

數(shù)據(jù)不流動

數(shù)據(jù)在不同的表之間流動

數(shù)據(jù)的訪問特點

讀很頻繁，很少寫

讀很頻繁，很少寫，每次僅訪問表中的極少量數(shù)據(jù)

只插不改不刪，數(shù)據(jù)生成后只用來備查

讀和寫都很頻繁，不光是插還要改和刪

數(shù)據(jù)量

數(shù)據(jù)量小，一般在萬條以內

數(shù)據(jù)量大，一般在幾萬條到上億條以內

數(shù)據(jù)量很大，一般在幾十萬條到上億條以內

數(shù)據(jù)量很大，一般在幾千條到上千萬條以間

數(shù)據(jù)的增長量

幾乎不增長

增長緩慢

增長快

增長快

成功應用數(shù)據(jù)存儲模式的步驟

建立數(shù)據(jù)存儲模式管理小組

正如同大型程序的核心模塊會成立專門的核心開發(fā)小組一樣，大數(shù)據(jù)量也值得成立專門的管理團隊進行數(shù)據(jù)存儲模式管理。

開發(fā)團隊往往是按照業(yè)務模塊來劃分的，核心表被各個業(yè)務模塊使用，但沒有專人管理核心表。幾乎伴隨每一次大的業(yè)務升級，核心表都會被添加字段，少則幾個，多則十幾個。表面上，添加的字段節(jié)省了某個業(yè)務的關聯(lián)查詢的時間，但其惡果是核心表的過度膨脹和關系型模型的模糊，最終會拖累整體業(yè)務性能。

數(shù)據(jù)存儲模式管理小組能夠站在業(yè)務的整體角度去審查核心表的變動是否合理，維護關系型模型和控制核心數(shù)據(jù)的整體規(guī)模。更重要的是，他們能夠根據(jù)數(shù)據(jù)規(guī)模和業(yè)務特點制定統(tǒng)一的數(shù)據(jù)存儲模式，并在各個開發(fā)小組中推廣。在存儲模式實施有困難的時候，小組能給開發(fā)者提出有益的設計建議。

架構中的存儲設計模式

對重要的商業(yè)應用來說，數(shù)據(jù)庫并非只有一個，而是1（生產庫）+N（容災庫）的方式在運行。再加上數(shù)據(jù)增長到一定量級時，數(shù)據(jù)庫的物理拆分將不可避免，從一個大數(shù)據(jù)庫變成多個小的數(shù)據(jù)庫。面對這么多的數(shù)據(jù)庫，軟件架構師需要從更高層面進行數(shù)據(jù)存儲設計。

首先，架構師要考慮的是如何利用容災庫來減輕生產庫的壓力？容災庫和生產庫是準實時同步，數(shù)據(jù)一般是相差一天或者更短時間，最新的技術已經能做到容災庫在只讀打開的狀態(tài)下與生產庫保持同步。容災庫適合用于備份、抽取數(shù)據(jù)源、綜合統(tǒng)計、報表和壓力測試。要做到容災庫接管綜合統(tǒng)計和報表功能，架構師需要解決查詢的跨庫問題和生成報表的寫數(shù)據(jù)庫問題。

另一個重要的問題是如何對數(shù)據(jù)庫做拆分？傳統(tǒng)的思路是按照行政區(qū)域劃分數(shù)據(jù)庫，這種方式的優(yōu)點在于容易操作，程序的改造難度小，缺點在于核心數(shù)據(jù)同步的工作量大，容易出現(xiàn)數(shù)據(jù)不一致。另一種思路是核心庫加衛(wèi)星庫的方式，即核心庫存放活躍的核心數(shù)據(jù)，衛(wèi)星庫存放休眠的過程數(shù)據(jù)。這種類似分區(qū)數(shù)據(jù)庫的工作模式有利于核心業(yè)務的資源保障，對架構師的設計能力提出了很高挑戰(zhàn)。

了解存儲技術的最新趨勢

如同已經發(fā)生的每一次技術浪潮一樣，存儲技術的巨大進步會給存儲模式設計帶來顛覆式的影響。我們需要了解存儲技術的最新趨勢，并在數(shù)據(jù)存儲模式設計中考慮這一變化。

這里就以存儲介質的技術變革，來舉例分析存儲技術的進步對存儲模式設計的影響。由于傳統(tǒng)磁盤的機械式運動，造成物理讀和邏輯讀，以及順序讀和離散讀的巨大性能差別。因此，以往的設計思路是將數(shù)據(jù)盡可能的緩存到內存中，避免磁盤I/O，尤其是避免磁盤離散讀。隨著固態(tài)硬盤的技術成熟，物理讀和邏輯讀，以及順序讀和離散讀的性能差別會大幅縮小，取而代之的是讀和寫的巨大性能差別。新的設計思路需要把重點放在減少數(shù)據(jù)流動，減少事務提交等方面上來。

結束語

如今，全世界的數(shù)據(jù)庫都面臨數(shù)據(jù)量的爆炸式增長，多核CPU、內存數(shù)據(jù)庫、固態(tài)硬盤，甚至超高性能的多機集群等硬件性能的提升逐漸追不上數(shù)據(jù)增長的速度，我們必須要開拓新的優(yōu)化思路來建設一個高效穩(wěn)定的信息系統(tǒng)。

我們需要深刻的理解數(shù)據(jù)——識別數(shù)據(jù)流向、數(shù)據(jù)訪問特點、數(shù)據(jù)量、數(shù)據(jù)增長量和數(shù)據(jù)生命周期等數(shù)據(jù)特性，并據(jù)此展開核心數(shù)據(jù)和過程數(shù)據(jù)的存儲設計、程序設計和架構設計，才能滿足不僅要實現(xiàn)功能正確，還必須足夠快的商業(yè)需要。

轉載請注明出處：華為云博客 https://portal.hwclouds.com/blogs

存儲 數(shù)據(jù)庫 存儲

版權聲明：本文內容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內刪除侵權內容。

版權聲明：本文內容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內刪除侵權內容。