?當前存在為各種專門場景設計的數據庫系統，在實踐中可以依據具體應用的規模、復雜性和功能需求來選擇合適的數據庫。這與早期信息化解決方案中“用一套Oracle數據庫解決所有問題”形成鮮明的對比。數據庫有增、查、改、刪四大操作，簡稱CRUD（Create、Read、Update、Delete）操作。不同的數據庫技術設計的本質都是對這四種操作的性能進行優化和平衡。

1.關系型數據庫與NoSQL

關系型數據庫一直是信息技術發展的主流。隨著大數據的出現，由于關系型數據庫在應對大數據時遇到挑戰，因而在面向某些特定場景時，全新的NoSQL數據庫技術開始興起。NoSQL數據庫能夠提供豐富的數據模型支持，可實現大吞吐量“讀”或“寫”的高效率，以及良好的擴展性。NoSQL數據庫技術普遍選擇犧牲支持復雜的SQL及ACID事務來換取彈性擴展能力，通常不保證強一致性，但支持最終一致性。與此同時，關系型數據庫也在不斷演進，通過支持列式存儲模式、MPP分布式架構，在保持一定關系數據處理能力的基礎上，也能夠實現良好的分析性能支持。在關系型數據庫技術與NoSQL數據庫技術之間，不同路線的技術不是完全的替代關系，而是互補關系，綜合運用可以更好地應對不同場景的需求。

（1）關系型數據庫理論及優勢

關系型數據庫（Relational Database）是建立在嚴謹的關系數據模型基礎上的，支持強事務，通過統一結構化語言（SQL）操作。關系型數據庫主要面向事務（Transaction）設計，要求保證事務過程（Transaction Processing）的正確執行與數據的正確性，即使執行過程中遇到出錯、斷點、系統崩潰等異常也是如此。關系型數據庫嚴格遵循ACID原則。

原子性（Atomicity）：保證一個事務被看作一個單元，事務中的所有操作，要么全部完成，數據庫更新到新的狀態，要么全部不完成，數據庫狀態保持不變。

一致性（Consistency）：保證一個事務執行前后的數據庫狀態都是有效的。有效狀態（Valid State）是指事務完成后數據庫的數據符合所有預定義的規則：約束（Constraint）、級聯（Cascades of Rollback）、觸發器（Trigger）及其任意組合。一致性可以阻止數據庫被非法的事務所破壞，例如參照完整性（Referential Integrity）保證了主鍵-外鍵關系。一致性并不保證從應用層看事務是正確的。

隔離性（Isolation），又稱獨立性：保證事務并發執行與串行執行所獲得的數據庫狀態相同。為了提高數據庫的處理效率，事務通常需要并行執行，例如多個事務同時讀取和寫入一個表。為了保持隔離性，需要對事務進行并發控制，不同級別的控制方法提供不同的效率與事務間影響的平衡。

?持久性（Durability）：保證一旦事務被提交，即使存在系統故障，事務也一定是生

效的。

為實現以上原則，數據庫需要實現同步鎖、多版本并發控制（MVCC）、日志（Log）等功能，例如在提交事務前，先把事務寫入WAL（Write Ahead Log）。關系型數據庫無論是在理論，還是在技術、商業產品、產業生態方面都十分成熟，易于理解、方便使用、維護簡單，除了支持事務，也支持一定量級的分析應用。

（2）關系型數據庫在應對大數據時遇到的挑戰

關系型數據庫技術難以應對數據量大、增長速度快、高響應時效、內容豐富等大數據場景的數據處理要求，舉例如下。

低延遲高并發：大數據時代要求支持海量數據的高效存儲和訪問，但關系型數據庫受事務、架構約束，隨著數據量的增長，其讀寫性能會迅速下降，難以實現高并發、實時動態大數據量的獲取和更新。

擴展性：大數據時代用戶量可能出現爆發式增長，需要數據系統具有快速擴展的能力，而關系型數據庫難以方便、靈活、短周期、低成本地滿足這一需求。

模型自由：對于半結構化（如JSON）、非結構化數據（如文檔、影像），關系型數據庫只能將其存儲為一個二進制數據塊，無法支持對數據內容的檢索、分析等處理。

大規模的數據讀取：在進行數據統計分析時常常需要批量讀取數據，隨著數據量的增長，傳統關系數據庫在需要批量掃描對數據進行讀取時效率不足。

常見的解決方案有兩種：縱向擴展（Scale Up）與橫向擴展（Scale Out）。對于關系型數據庫，縱向擴展是提升單服務器的性能，這是IOE（IBM、Oracle、EMC）類廠商給大型銀行等機構提供的常見一體機解決方案，上限瓶頸明顯，且成本高昂；橫向擴展是通過讀寫分離、分庫分表等方法在數據庫設計與應用層實現的，這會使得應用層實現、維護都變得十分復雜和僵化，無法應對需求的快速變化。隨著數據量的不斷增長，我們需要不斷調整方案，效率十分低下，且容易出錯。

（3）NoSQL數據庫的特點

NoSQL主要指非關系型、分布式、不提供ACID的數據庫設計模式，支持快速大規模的水平擴展。對NoSQL最普遍的解釋是“非關系型的”。NoSQL是一組相互非常不同的數據庫系統的泛稱，并且難以用一個分類去劃分。NoSQL數據庫的數據模型主要包括鍵-值模型（Key-Value）、列族模型（Wide Column）、文檔模型（Document）、圖模型（Graph）。另外，DB-ENGINES網站將搜索引擎（Search Engine）系統也視為NoSQL數據庫，但嚴格來講，搜索引擎并不是普遍意義上的數據庫。DB-ENGINES網站還認為NoSQL包含RDF存儲庫、Native XML DBMS、內容存儲庫。

通過放松標準關系數據模型、ACID原則要求支持，NoSQL數據庫具有如下優點：

更高的性能；

易于在不同節點上分布數據（如分片），從而實現擴展性（scalability）和容錯能力（fault tolerance）；

通過使用無模式（schema-free）的數據模型來提高靈活性；

管理簡化。

2.鍵-值模型數據庫

當前鍵-值數據庫使用極其廣泛，適用于高性能緩存場景，例如會話、用戶配置、購物車等場景的數據存儲，單條超低延遲讀/寫，高并發要求，內容簡單且相互獨立，但不適用于事務處理、多鍵關聯數據、統計分析。Amazon的工程師對他們自己的數據庫查詢和使用情況進行了分析，發現70%的工作負載都是單鍵值操作，而且鍵值操作很少使用Oracle數據庫提供的關系功能，另外20％的工作負載訪問也僅限于一個表，只有10％的工作負載需要跨多個鍵訪問數據而使用到關系型數據庫的功能。

（1）鍵-值模型簡介

從使用方式來看，鍵-值模型數據庫是最簡單的NoSQL數據庫。客戶端可以根據鍵對其所對應的值進行CRUD操作。鍵值數據庫支持的鍵值類型十分豐富。

鍵-值模型極大地簡化了傳統的關系數據模型，相當于只有兩個字段的表。鍵-值模型的實現類似于Map結構，在鍵和值間建立映射關系。鍵-值模型數據庫面向高效訪問場景，使用非常廣泛，典型的如Memcached、Redis、DynamoDB。

（2）Redis

Redis是開源的、鍵-值模型NoSQL數據庫，適合在高速響應場景下作為數據緩存使用，同時提供持久化數據的能力。Redis集群使用主從架構實現高可用。

Redis不是簡單的鍵值存儲數據庫，而是一個數據結構服務器。這里的值不局限于簡單的字符串，還包括幾種復雜的數據結構。Redis的每條記錄都有一個鍵和一個值。鍵是二進制安全的，這意味著可以使用任何二進制序列作為鍵，如可以是一個字符串，也可以是一個JPEG圖片文件的內容，最大支持512MB，但太長的鍵會影響存儲效率和查詢效率。值支持五種數據結構類型：String、List、Hash、Set、Zset。不同數據結構類型的說明如下。

• List是按照插入順序排列的字符串列表。
• Hash是字段和值都是String類型的映射表。
• Set是成員為String類型的不重復無序集合。
• Zset（或Sorted set）與Set的區別是每個元素關聯一個分值，元素按分值從小到大排序。

為了支持多種值類型、優化存儲、內存回收、共享對象等功能，Redis的值存儲使用一個內部定義的RedisObject結構體。該結構體包括五個字段：值的數據結構類型（type）、內部編碼格式（encoding）、最后一次訪問時間（lru）、被引用次數（refcount）、值或值的指針（*ptr）。該結構體在64位系統中占16個字節。Redis支持多種數據結構類型，在不同的使用場景，Redis會選擇合適的內部編碼，以節省內存或優化性能，最多可以省90%的內存（平均為50%），并且這對于用戶和API來說是透明的。內部編碼涉及如下內容。

String有三種內部編碼：int（8字節）、embstr（≤44字節）、raw（>44字節）。

當List的元素較少時，使用ziplist（壓縮列表）存儲；當元素增多，超過配置的閾值時，List會自動轉換為linkedlist（雙向鏈表）存儲。ziplist是Redis為了節約內存而專門開發的一種連續的數據結構。

同樣，Hash和Zset在數據量小時也使用ziplist存儲，當超過配置的閾值后會分別轉存為hashtable（哈希表）和skiplist（跳躍鏈表）。

當Set的元素較少時，使用intset（整數集合）存儲，當超過配置的閾值后則轉存為hashtable（哈希表）。

3.列族模型數據庫

列族模型數據庫能夠支持大量的動態列，與文檔模型數據庫具有相似的無模式特性，但實現方式完全不同。列族可以看作二維的鍵-值存儲。注意，列族模型與列式存儲不是一個概念。列族模型數據庫支持低延遲單條數據讀寫、高并發、靈活的表結構調整，但不適合做需要大規模批量讀取的統計數據分析。

（1）列族模型簡介?

在列族模型數據庫中預先定義的是列族而不是列。一個列族下可以有很多個列，且每個列族下列的個數可以不一樣。一個列族下的數據存儲在一起。列族在建表的時候定義，一般是不可變的，但在后續的使用中還可以添加列。列族不需要像關系型數據庫的列那樣預定義數據類型，只要數據可以轉為字節數組即可。比較常見的開源列族模型數據庫有Hbase、Cassandra/ScyllaDB。

（2）HBase

HBase的設計思想來源于2006年Google發布的Bitable論文。HBase是一個開源、分布式、可擴展、面向列族的NoSQL數據庫，主要解決超大規模數據集的實時、隨機訪問等問題，其底層文件存儲基于HDFS。

HBase采用主從架構，主要由HBase Master（也稱HMaster）和HRegionServer構成，同時使用ZooKeeper協同管理。HBase將表橫向切分來實現分布式存儲，將一個表分為多份（HRegion），同一個表的不同HRegion分布在不同的RegionServer上。HMaster負責表的創建、刪除等DDL（數據庫定義語言）操作，同時在新表上線、集群啟動、負載均衡時，負責將各個表的HRegion分配至RegionServer上。ZooKeeper維護集群中所有節點的狀態，比如節點出現了故障等。

HBase中的表由行和列族構成，列族對應的邏輯概念是存儲。HBase是先寫內存，再將內存中的數據刷寫至HDFS，因此存儲分為內存中的MemStore和HDFS上的StoreFile。HBase架構示意圖如圖1所示。

?

▲圖1 HBase架構

4.文檔模型數據庫

文檔模型數據庫是無模式的，適合處理半結構化數據，如日志、網頁、內容等，無須將文檔解析為獨立字段的表，但支持按文檔內的字段進行查詢分析等操作，不適合復雜事務場景。

（1）文檔模型簡介

文檔模型數據庫用于儲存、檢索和管理面向文檔的信息。與關系型數據庫按字段處理不同，在文檔模型數據庫中，文檔是信息處理的基本單位。文檔格式其實是半結構化數據，一般是鍵值對的一個有序集，支持嵌套結構，例如XML、JSON、BSON等。文檔模型沒有預定義的模式，文檔的鍵和值不要求固定類型和大小。常見的文檔模型數據庫有CouchDB、MongoDB等。

（2）MongoDB

MongoDB不需要像關系型數據庫那樣預定義表結構，而是通過BSON將數據和結構保存在一起。參考關系型數據庫的庫、表、行、列（字段）等層次，MongoDB的邏輯結構分層依次是庫、集合、文檔、字段，但這些庫、集合的作用與關系型數據庫中的庫、表完全不同，主要是為了便于用戶分類組織管理數據。

字段：每個字段包含字段名和字段值兩部分。字段名是字符串類型，區分大小寫，字段名不能重復。字段值可以是string、int、long、double、boolean、子文檔、數組等。

文檔：MongoDB中數據的基本存儲單元。文檔使用BSON結構表示，文檔中的字段是有序的，不同序則是不同文檔。每個文檔都有一個默認的_id鍵，相當于關系型數據庫中的主鍵，默認是ObjectId類型。若用戶不顯式定義文檔的_id值，MongoDB會自動生成。

集合：集合由若干條文檔記錄構成，集合是無模式的，即集合中的文檔可以擁有不同的結構。在集合上可以對文檔中的字段創建索引。

數據庫：一個數據庫中可以包含多個集合。

5.圖模型數據庫

圖模型數據庫適合處理知識圖譜、推薦、反欺詐、物流、社交關系等場景。近年來，圖模型數據庫是各種數據庫類型中發展最快的。當前人氣最高的圖模型數據庫仍然是2007年發布的開源圖數據庫—Neo4j，但Neo4j不支持橫向擴展，在處理數據規模上受限于單機，集群模式僅用于高可用和提高查詢性能。支持水平擴展的圖模型數據庫有從Titan發展來的JanusGraph，其底層依賴Hbase、ScyllaDB等作為外部存儲。分布式原生圖模型數據庫有2019年開源的Nebula和2017年發布的TigerGraph（未開源）。

（1）圖模型簡介?

圖模型數據庫使用圖結構進行語義查詢，主要是使用節點、邊、屬性來描述和存儲數據。圖模型可以高效地存儲實體“關系”數據，這個“關系”與關系型數據庫的含義不同。最常見的關系數據的例子是人與人之間的關系、知識圖譜。

以圖形式表達實體之間的關系非常便于關系的檢索，無論是正向的還是反向的。如果使用關系型數據庫處理“關系”數據，需要使用外鍵將數據關聯起來，在檢索時需要執行表間的JOIN操作，計算成本很高，且不便于反向關系查找。

圖結構就是頂點、邊以及屬性的集合。

頂點：圖中的節點，每個頂點會有一個唯一的ID，頂點可以擁有一個或者多個屬性描述。

邊：邊用來連接各個頂點，表達節點之間的關系，邊可以是無方向的，也可以是單向或者雙向的，邊也可以擁有屬性和ID。

圖通常使用鄰接矩陣或鄰接表等存儲模式。鄰接指的是頂點之間的關系，如果兩個頂點之間有邊，則這兩個點互為鄰接點。鄰接矩陣與鄰接表分別使用數組與鏈表作為基礎存儲數據結構，所以數組與鏈表的優缺點就是鄰接矩陣與鄰接表的優缺點。

鄰接矩陣使用二維數組來存儲圖關系，矩陣的行和列都代表頂點，相同行號和列號對應同一個頂點。如果兩個頂點之間存在關系，則在數組的相應位置存儲相應的數字。對于無向圖，則數組可以僅僅是0、1值，0代表無關系，1代表有關系。使用數組存放數據，可以實現數據的快速定位和更新，但如果對于頂點量大但邊稀疏的圖，例如路網圖，會存在很大的存儲浪費，因此鄰接矩陣適合頂點少、關系稠密的關系圖。

鄰接表使用鏈表存儲圖關系，頂點信息存儲在一個一維數組中，數組的每個元素是一個結構體，對應一個頂點，并且每個元素中存儲一個指向該元素鄰接點鏈表的指針。

（2）Neo4j

Neo4j是一個有商業支持的開源圖模型數據庫，它是基于圖原生底層存儲設計，而不是嫁接在關系型數據庫之上設計的。Neo4j具有以下特點：ACID事務處理模式、高可用性、可擴展到數十億節點和關系、通過遍歷可實現高速查詢、強大的圖形搜索能力。Neo4J通過Cypher語言來操作數據庫。Cypher是當前圖模型數據庫領域主流的圖查詢語言之一。

Neo4j不支持數據規模的水平擴展，但支持高可用集群模式Neo4j HA。Neo4j由獨立的主數據庫（Master）和從數據庫（Slave）組成，Master主要負責數據的寫入，Slave從Master同步數據更改，Slave是Master的精確副本，以提高查詢負載支持。如果Master失效，集群將選舉出新的Leader作為新的Master。

6.搜索引擎系統

搜索引擎系統不是面向數據庫場景設計的，但在某些場景可以替代數據庫，作為存儲系統，例如文檔數據處理、數據分析。搜索引擎系統相對于提取數據系統具有如下特點：

• 全文檢索；
• 詞干提取；
• 復雜的搜索表達式；
• 搜索結果的排名和分組；
• 分布式搜索以實現高可擴展性。

搜索引擎系統需要的存儲空間比其他數據庫系統大很多，另外，為了提高搜索的性能，在插入和更新時需要消耗比較多的計算和存儲資源去建立索引。流行的開源搜索引擎系統有Elasticsearch、Solr，這兩個都是在全文檢索引擎工具包Lucene基礎上實現的。

Elasticsearch是一個分布式的開源全文搜索和分析引擎，適用于所有類型的數據，包括文本、數字、地理空間、結構化和非結構化數據。Elasticsearch會存儲文檔并構建倒排索引，支持近實時的、快速的全文本搜索，可以找到包含詞匯的全部文檔。它通常與Logstash和Kibana配合使用，Logstash進行日志采集，Kibana做可視化展現，合稱為ELK，在日志處理領域應用非常廣泛。

7.關系模型MPP數據庫

在需要大規模數據讀取的數據分析場景，傳統的單機數據庫已無法滿足需求，所以一些數據庫廠商推出了MPP數據庫一體機，但價格昂貴。這時運行在普通硬件集群上的開源MPP數據庫軟件出現了，最典型的就是Greenplum。

（1）Greenplum介紹

Greenplum數據庫系統是基于PostgreSQL開源技術開發的，實際上是由一組PostgreSQL數據庫節點組合而成，可以作為一個單一數據庫管理系統使用。PostgreSQL是功能最為完善、健壯的開源關系型數據庫，因此Greenplum也是所有開源MPP數據庫系統中功能支持最為完善的。數據庫用戶與Greenplum數據庫進行交互，就像與常規PostgreSQL DBMS進行交互一樣。Greenplum數據庫的特點如下所示。

• 并行數據加載；
• 實現新的查詢規劃器；
• 可以使用追加優化（append-optimized）存儲；
• 支持行存儲，也支持列存儲，可以針對每個表來指定。

（2）Greenplum數據庫架構

Greenplum的設計初衷是管理大規模分析數據倉庫和BI系統。Greenplum數據庫通過在多個服務器之間分布數據和工作負載來存儲與處理大量數據，其體系架構實際上是由多臺PostgreSQL數據庫服務器組成的矩陣。

Greenplum中的服務器節點按功能可分為兩種：Master實例和Segment實例。Greenplum架構示意圖如圖2所示。

▲圖2　Greenplum架構

Master是Greenplum數據庫系統的入口點，客戶端通過Master上的數據庫實例連接并提交SQL語句。Master上存儲全局系統目錄，但不包含任何用戶數據。Segment上存儲和處理實際數據，它是獨立的PostgreSQL數據庫，每個數據庫都存儲一部分數據并執行大部分查詢處理。Master協調所有Segment數據庫實例的工作。當用戶在Master節點上執行SQL查詢時，Master會將SQL以及SQL Plan分發到所有Segment節點，待Segment處理好后，再由Segment將數據發回Master節點。

Segment運行在被稱作Segment主機的服務器上。一臺Segment主機通常運行2～8個Greenplum的Segment，具體取決于CPU核數、RAM、存儲、網絡接口和工作負載。通常Segment實例所在主機應采用相同的配置，集群的互聯網推薦采用萬兆網絡。

本文摘編于《數據應用工程：方法論與實踐》，經出版方授權發布。（書號：9787111704096）轉載請保留文章出處。?