數(shù)據(jù)庫大數(shù)據(jù)量存儲結構研究

劉丹 任浩然

摘 要：隨著大數(shù)據(jù)云計算技術逐步成為數(shù)字經(jīng)濟的基礎設施，規(guī)?；?、業(yè)務化、智能化的海量數(shù)據(jù)的存儲在面對快速變化的業(yè)務需求和多元化的查詢需求時，越來越不能靈活地根據(jù)業(yè)務需求進行快速的迭代更新，對多元化查詢需求的快速響應和容錯變得越來越困難。傳統(tǒng)的關系型數(shù)據(jù)庫支持ACID，對成熟的業(yè)務系統(tǒng)有著良好的支持，一旦核心的業(yè)務出錯可以立即回滾;互聯(lián)網(wǎng)的業(yè)務追求擁抱變化，追求快速響應和迭代以及結果的最終一致和容錯性。在此背景下，文章提出一種新的多元且靈活的數(shù)據(jù)庫大數(shù)據(jù)量的存儲結構，其支持國內(nèi)外絕大多數(shù)主流的數(shù)據(jù)計算引擎，在索引和多元化查詢方面的表現(xiàn)也更加優(yōu)異，可以更好地容錯和快速迭代更新。

關鍵詞：關系型數(shù)據(jù)庫;多元查詢;存儲結構

0? ? 引言

關系型數(shù)據(jù)庫憑借其優(yōu)秀的行列二維表的關系數(shù)據(jù)模型，在互聯(lián)網(wǎng)和工業(yè)領域被廣泛地使用，主流的關系型數(shù)據(jù)庫是Oracle，MySQL等，它們在業(yè)務成熟且流程固定的場景下，存儲和應用非常標準和規(guī)范化。

通用的SQL語言可以支持很多復雜場景下的業(yè)務需求，關系代數(shù)為了維護ACID的強一致性，其必須預先定義固定二維表，缺乏靈活性和容錯性，近年來NoSQL類的數(shù)據(jù)庫應運而生，在高并發(fā)讀寫和降低硬盤I/O方面有了很大的速度優(yōu)勢，容易擴展。本文在對比研究了關系型和NoSQL數(shù)據(jù)庫的數(shù)據(jù)存儲結構后，提出一種新的多元且靈活的大數(shù)據(jù)量的存儲結構，其支持大數(shù)據(jù)生態(tài)的各種主流的開源數(shù)據(jù)計算引擎，能夠快速迭代，在索引和多元化查詢方面也有著不錯的表現(xiàn)。

1? ? 關系型數(shù)據(jù)庫數(shù)據(jù)存儲結構

1.1? B-Tree

B-Tree是一種多路搜索樹的數(shù)據(jù)結構，它由樹的簡單結構演變而來，將左右子樹分為多叉的樹形結構，數(shù)據(jù)在每個節(jié)點都存在但不存儲數(shù)據(jù)的副本，搜索性能和二叉查找樹的級別相當，但整個樹的高度比二叉的平衡查找樹低，從而避免了磁盤的多次讀取，適用于存儲和搜索數(shù)據(jù)。關系型數(shù)據(jù)庫通常使用B-Tree的結構作為非聚簇索引的底層數(shù)據(jù)結構，先查到聚簇索引的主鍵值，然后通過聚簇索引的主鍵值查找到真正行的詳細數(shù)據(jù)。

1.2? B+Tree

B+Tree[1]也是一種多路搜索樹，它是由B-Tree的數(shù)據(jù)結構演變而來，把所有的數(shù)據(jù)放到了葉子節(jié)點，葉子節(jié)點之間加入了一個個指針指向下一個葉子的地址，在做范圍數(shù)據(jù)查找時具有優(yōu)勢。關系型數(shù)據(jù)庫通常使用B+Tree的結構作為聚簇索引的底層數(shù)據(jù)結構，盡量將主鍵存儲在B+Tree的非葉子節(jié)點中，如果其中的某個查詢在業(yè)務場景中使用得很頻繁，可以考慮遵循最左的子樹的索引覆蓋的原則將多個字段作為聯(lián)合索引優(yōu)化查詢的性能。

2? ? NoSQL數(shù)據(jù)庫數(shù)據(jù)存儲結構

2.1? KeyValue存儲

數(shù)據(jù)的存取都直接通過定義好的Key。在不需要實物支持和固定模式的情況下，注重對大數(shù)據(jù)讀寫性能的提升，目前主要的KV數(shù)據(jù)庫有Memcached，Redis等。Memcached支持多種語言并保證分布的均勻性，Redis是將所有的KV都存于內(nèi)存，速度很快，值的類型也比其他數(shù)據(jù)庫的類型豐富。此類KV數(shù)據(jù)庫適用于消息隊列、實時系統(tǒng)和高頻讀低頻寫的場景。

2.2? 列存儲

查詢密集型的OLAP[2]場景下，對表的數(shù)據(jù)一般是取某幾列的數(shù)據(jù)，對數(shù)據(jù)表的讀取按行讀非常消耗性能，因為并不需要行中的所有數(shù)據(jù)，一般是按列去存儲數(shù)據(jù)。列存儲可以對相同數(shù)據(jù)類型的數(shù)據(jù)進行壓縮但在增加、刪除、修改數(shù)據(jù)頻繁的OLTP場景下不太適用。傳統(tǒng)RDBMS應對復雜關系運算、關系挖掘能力有限，列存儲讓服務器具備橫向擴展的能力，在批處理下可以顯著地減少CPU的使用率。

2.3? JSON存儲

JSON直觀簡單不依賴于位置，目前主流的JSON類數(shù)據(jù)庫是MongoDB和SequoiaDB。前者面向集合的設計理念能夠做到靈活的模式;后者使用交互式的JSON格式定義。JSON類型的存儲帶來的靈活性得益于其直觀簡單的數(shù)據(jù)格式。

3? ? 多元靈活的存儲結構

結構化的數(shù)據(jù)最為常見，格式固定，支持高吞吐寫入以及大規(guī)模存儲，想要多元靈活的大數(shù)據(jù)結構化的存儲，采用集中式的存儲模式，作為業(yè)務數(shù)據(jù)庫的大寬表，離線批量計算的流入和流出需要支持到PB級別。固定的組合查詢許多的維度表會經(jīng)常發(fā)生變化，大寬表機制不能完全解決問題，因此使用MPP的方式對單個查詢進行同步，限制數(shù)據(jù)量，以避免非常昂貴的、沒有意義的計算。查詢進入MPP時，采用MurmurHash算法，算出一個值作為指紋值。Meta信息中，存儲該指紋值和行數(shù)。通過定期執(zhí)行任務，去同步該查詢數(shù)據(jù)，同入MPP一樣，遍歷每行每列，算出新的指紋值。如果指紋值不變，則結束;反之，將該查詢重新入庫，記住新的指紋值，在新數(shù)據(jù)入MPP庫的時候不重復計算，以得到最好的性能，從而支持多元靈活的大數(shù)據(jù)結構化的存儲。無法結構化的數(shù)據(jù)，例如圖片、文件、視頻一般使用HDFS[2]存儲，沿用成熟的HDFS方式采用面向資源的分布式系統(tǒng)架構設計，所有組件都可擴展，避免因單點失效的故障問題。將非結構化數(shù)據(jù)以文件的方式存儲在文件系統(tǒng)中，同時將指向文件路徑存儲在數(shù)據(jù)庫表中，這種方式數(shù)據(jù)讀寫的速度較快。

4? ? 結語

本文研究了多種業(yè)內(nèi)主流的傳統(tǒng)關系型數(shù)據(jù)庫和NoSQL的存儲結構，在面對快速變化的業(yè)務需求和多元化的查詢需求時，提出一種多元且靈活的數(shù)據(jù)庫大數(shù)據(jù)量的存儲結構，在索引和多元化查詢方面的表現(xiàn)更加優(yōu)異，可以更好地容錯和快速迭代更新。但還存在一些不足，該存儲結構數(shù)據(jù)派生能力弱不能做到數(shù)據(jù)寫入主存儲后會由主存儲再向輔存儲進行同步、運維復雜核心依賴是Zookeeper和HDFS，需要經(jīng)驗豐富的專業(yè)團隊運維管理和熱點處理能力差無法保證數(shù)據(jù)訪問的熱度均勻，這些是以后工作的方向和重點。

[參考文獻]

[1]WANG C，BRIHADISWARAN G，JIANG X，et al.Circ-Tree： A B+-Tree variant with circular design for persistent memory[J].IEEE Transactions on Computers，2021（99）：1.

[2]SOUNTHARRAJAN S，RAJAN C，SANKARANANTH S，et al.HDFS-based parallel and scalable pattern mining using clouds for incremental data[J].International Journal of Computer Aided Engineering and Technology，2020（1/2）：28.

（編輯 王雪芬）