前言

做為目前主流的模型數據庫類型，關系型數據庫的架構隨著業務規模的增長做出相應的變化，本章我們來學習關系型數據庫架構的變化以及主流的應用場景。

關系型數據庫架構

隨著業務規模增大，數據庫存儲的數據量和承載的業務壓力也不斷增加，數據庫的架構需要隨之變化，為上層應用提供穩定和高效的數據服務。

上圖所示的數據庫架構中單機與多機的區別是按照主機數量進行區分，這里的主機指的是數據庫服務器。單機架構就是指單個數據庫主機，在單機架構中又分為了單主機和獨立主機，所謂的單主機指的是應用和數據庫都放在一個主機上，這對主機的性能負擔過重，因此有了獨立主機，將應用和數據庫分開，數據庫就放在專門的數據庫服務器上，應用就放在專門的應用型服務器上。
多機架構是通過增加服務器數量來提升整個數據庫服務的可用性和服務能力，多級架構分為了分組和分片，分組指的是對每個服務器區分角色，這里分為了主備、主從、多主結構。不管是主備、主從還是多主結構本質上都是多個數據庫結構相同，儲存數據相同的服務器之間進行數據同步。而分片結構則是將數據按照算法分攤在各個節點上，每個節點維護自己的數據庫數據。

單機架構

為了避免應用服務和數據庫服務對資源的競爭，單機架構也從早期的單主機模式發展到數據庫獨立主機模式，把應用和數據服務分開。應用服務可以增加服務器數量，進行負載均衡，增大系統并發能力。

優點部署集中，運維方便。一個數據庫即一個主機，對單機結構服務器進行維護很方便，但同樣出現故障也很麻煩。

缺點	可擴展性	數據庫單機架構擴展性只有縱向擴展（Scale-up）。通過增加硬件配置來提升性能，但單臺主機的硬件可配置的資源會遇到上限。
	存在單點故障	擴容的時候往往需要停機擴容，服務停止。硬件故障導致整個服務不可用，甚至數據丟失。單機會遇到性能瓶頸。

早期互聯網的LAMP（Linux，Apache，Mysql，PHP）架構的服務器就是最典型的單機架構的使用。

單主機和獨立主機的區別

多機架構

分組架構：主備

在主備架構中數據的讀寫都在一臺設備上進行，這臺設備叫做主機（Master），而另外一臺設備被稱為備機（Backup），備機在正常情況下不會被使用，只會進行主備直接數據的同步，當主機出現故障后，備機將替代主機的作用進行數據讀寫。同一時間內只有一臺設備能夠對外提供服務。

優點應用不需要針對數據庫故障來增加開發量。相對單機架構提升了數據容錯性。解決了單點故障情況。

缺點	資源的浪費，備機和主機同等配置，但長期范圍內基本上資源限制，無法利用。性能壓力依舊在一臺設備上，無法解決性能的瓶頸，當出現故障時主備機切換需要一定的人工干預或者監控。

分組架構：主從

在主從結構中，主機依舊只能有一臺，但是從機可以有多臺，根據業務需求進行橫向的擴展。應用在主機上進行寫入、修改、刪除操作，把查詢請求分配到從機上，而從機與主機之間要進行數據的同步。

優點提升資源利用率，適合讀多寫少的應用場景。在大并發讀的使用場景，可以使用負載均衡在多個主機間進行平衡。從機的擴展性比較靈活，擴容操作不會影響到業務進行。

缺點	延遲問題，數據同步到從機數據庫時會有延遲，所以應用必須能夠容忍短暫的不一致性。對于一致性要求非常高的場景是不適合的。寫操作的性能壓力還是集中在主機上。主機出現故障，需要實現主從切換，人工干預需要響應時間，自動切換復雜度較高。

使用讀寫分離方式，應用開發模式有時也需要進行調整：應用開發過程中藥注意區分讀寫操作，讀操作提交到主機，寫操作提交到從機，近年來，不同的數據庫產品都出現了中間件來支持讀寫分離，數據庫中間件起到路由功能，會識別讀請求和寫請求，分別把讀寫操作分配到讀庫和寫庫上。如開源的mycat，vitness等。讀多寫少是相對而言，許多互聯網應用場景是讀的事務量遠遠大于寫的事務量，讀操作往往先成為性能瓶頸。另外寫庫出現故障期間，讀庫仍然可以對外提供服務，表現出“只讀”服務，根據從機的數量可以分為一主一從和一主多從。從機數量越多，雖然能夠提升數據庫讀的并發訪問量，但是從機之間的數據一致性問題也會帶來比較多問題。主機出現故障，自動切換就要解決多臺從機如何選舉出新主機的問題。對一致性要求不高的應用：如互聯網行業的社交網絡應用，對一致性要求高的場景：與金融，計費相關的應用。

分組架構：多主

多主架構，也稱為雙活，多活架構，在多主架構中，每一臺設備都不再區分從設備，都互為主從。每臺設備都能對上提供服務。

優點資源利用率較高的同時降低了單點故障的風險。

缺點	雙主機都接受寫數據，要實現數據雙向同步。雙向復制同樣會帶來延遲問題，極端情況下有可能數據丟失。數據庫數量增加會導致數據同步問題變得極為復雜，實際應用中多見雙機模式。

互為主從模式下的數據同步機制更為復雜，所以數據延遲、丟失都由可能存在，所以對于一致性要求非常高的場景，不適合使用這種架構。

共享存儲多活架構

共享存儲的多活架構（Shared Disk）是一種特殊的多主架構。數據庫服務器共享數據存儲，而多個服務器實現均衡負載。它解決了多主結構中的數據一致性問題，所有節點共享一個儲存設備，因此不會出現數據不一致的問題。

優點多個計算服務器提供高可用服務，提供了高級別的可用性。可伸縮性，避免了服務器集群的單點故障問題。比較方便的橫向擴展能夠增加整體系統并行處理能力。

缺點	實現技術難度大。當存儲器接口帶寬達到飽和的時候，增加節點并不能獲得更高的性能，存儲IO容易成為整個系統的性能瓶頸。

shared disk較為成功的案例目前，有Oracle的RAC（Real Application Cluster）產品， 微軟的SQL Server Failover Cluster

分片(Sharding)架構

分片架構主要表現形式就是水平數據分片架構，把數據分散在多個節點上的分片方案，每一個分片包括數據庫的一部分，稱為一個shard。多個節點都擁有相同的數據庫結構，但不同分片的數據之間沒有交集，所有分區數據的并集構成數據總體。

優點數據分散在集群內的各個節點上，所有節點可以獨立性工作。

GaussDB 100可以支持，單機，主備，主從的架構部署方式，分布式版本支持分片架構的部署方式。目前正在計劃開發共享存儲多活的架構。

無共享(Share-Nothing)架構

無共享架構非常類似共享式儲存多活架構，主不過不再使用共享的儲存，而是每個節點使用維護各自的獨立CPU/內存/儲存，不存在共享資源。各節點（處理單元）處理自己本地的數據，處理結果可以向上層匯總或者通過通信協議在節點間流轉。節點是相互獨立的，擴展能力強。整個集群擁有強大的并行處理能力。
可以說明一下，在硬件發展到當前時代，一個節點或一個物理主機上可以部署多個處理單元，所以Shared-Nothing的最小單元可能不是物理節點，而是邏輯上的虛擬處理單元。比如一個物理主機具有4核CPU，部署的時候可以部署4個數據庫實例，也就相當于擁有4個處理單元。

MPP架構 (Massively Parallel Processing)

大規模并行處理（Massively Parallel Processing）是將任務并行的分散到多個服務器和節點上，在每個節點上計算完成后，將各自部分的結果匯總在一起得到最終的結果。
分為了兩種架構

無Master架構所有節點都對等，可以通過任意的節點查詢和寫入數據，不存在性能瓶頸以及單點故障問題，可以進行橫向擴展。

共享Master架構	Master對外提供服務，任務由各個節點并行計算處理，結果上交給Master。

常見的MPP產品

無共享MasterVertica，Teradata。

共享Master	Greenplum，Netezza。

Teradata，Netezza是軟硬件一體機，GaussDB 200，Greeplum，Vertica是軟件版MPP數據庫

數據庫架構特點對比

關系型數據庫主流應用場景

聯機事務處理 (OnLine Transaction Processing)

OLTP是傳統關系數據庫的主要應用，面向基本的，日常的事務處理，例如銀行儲蓄業務的存取交易，轉賬交易等。業務量大，但是單個業務需要處理的數據量小，類似銀行中的每日流水，都是些基本的信息贈，刪，改，查操作。
特點：
大吞吐量：大量的短在線事務（插入、更新、刪除），非常快速的查詢處理。高并發，（準）實時響應。

典型的OLTP應用場景

零售系統、金融交易系統、火車機票銷售系統、秒殺活動等。

事務

而所謂的數據庫事務是數據庫執行過程中的一個基本邏輯單位，數據庫系統要確保一個事務中的所有操作都成功完成且結果永久保存在數據庫中。且一個事務中的操作要么都執行，要么都不執行。
例如：某人要在商店使用電子貨幣購買100元的東西，當中至少包括兩個操作，他的賬戶上少100元，而商鋪賬戶上多100元，這是一個事務，兩個操作，而數據庫要保證該兩個操作都成功且結果保存，不然就有可能發生用戶賬戶沒扣成功，反而商鋪賬戶上憑空多出來100元。
但在現實情況下，失敗的風險很高。在一個數據庫事務的執行過程中，有可能會遇上事務操作失敗、數據庫系統／操作系統出錯，甚至是存儲介質出錯等情況。這便需要DBMS對一個執行失敗的事務執行恢復操作，將其數據庫狀態恢復到一致狀態（數據的一致性得到保證的狀態）。為了實現將數據庫狀態恢復到一致狀態的功能，DBMS通常需要維護事務日志以追蹤事務中所有影響數據庫數據的操作。

聯機分析處理 (OnLine Analytical Processing)

OLAP是指對數據的查詢和分析操作，通常對大量的歷史數據查詢和分析。涉及到的歷史周期比較長，數據量大，在不同層級上的匯總，聚合操作使得事務處理操作比較復雜。數據處理方面聚焦于數據的聚合，匯總，分組計算，窗口計算等“分析型”數據加工和操作。從多維度去使用和分析數據。

典型的OLAP場景

報表系統，CRM系統。金融風險預測預警系統、反洗錢系統。數據集市，數據倉庫。

報表系統是產生固定周期報表的，或者上報固定格式報表數據的平臺或系統，如日報，周報，月報，月報，為經營決策提供電子化報表數據。

CRM系統	客戶關系管理系統，維護客戶，對客戶相關信息進行存儲，客戶行為進行分析， 對客戶進行響應，挽留和市場活動管理等綜合性業務系統平臺。
數據集市	就一般是面向一個組織中某個部門級別需求的應用需要，比如信用卡部門的分析需求。
數據倉庫	是面向企業級別的構建整個企業分析處理環境而產生的分析類平臺系統。

數據庫性能衡量指標

TPC（Transaction Processing Performance Council，事務處理性能委員會）
職責是制定商務應用基準測試標準（Benchmark）的規范、性能和價格度量，并管理測試結果的發布。制定的是標準規范而不是代碼，任何廠家依據規范最優地構造自己系統進行評測。推出了很多基準測試標準，其中針對OLTP和OLAP分別有兩個規范。

TPC-C規范

面向OLTP系統，主要包括兩個指標：
流量指標 tpmC（tpm – transactions per minuete, 即每分鐘測試系統處理的事務數量）。
性價比指標 Price（測試系統價格）/tmpC。

TPC-H規范

面向OLAP類系統
流量指標：qphH – Query per hour，即每小時處理的復雜查詢數量。需要考慮測試數據集合大小，分為不同的測試數據集，指定了22個查詢語句，可以根據產品微調。測試場景：數據加載，Power能力測試和Througput測試。

OLTP和OLAP對比分析

總結

以上是生活随笔為你收集整理的关系型数据库架构介绍及主流应用场景的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。