https://blog.csdn.net/solihawk/article/details/137807944
國產數據庫在技術架構上主要分爲集中式、基於中間件分佈式和原生分佈式架構，衍生出集中式架構和分佈式架構。那麼在這些部署架構中，從數據分佈的視角來看，在數據庫中數據分佈的形態是怎樣的。本文將簡要分析OceanBase、PolarDB、OpenGauss、GaussDB、GoldenDB、TiDB和TDSQL這幾個主流的國產數據庫的存儲類型及存儲引擎。
1、國產數據庫存儲類型
國產數據庫在技術架構上主要分爲集中式、基於中間件分佈式和原生分佈式架構，衍生出集中式架構和分佈式架構。那麼在這些部署架構中，從數據分佈的視角來看，在數據庫中數據分佈的形態是怎樣的，主要分爲本地存儲、集中式存儲和分佈式存儲：
- 本地存儲：從應用訪問的角度，表數據存儲在當前數據庫實例節點，數據的增刪改查都是在當前實例進行的。
- 集中式存儲：數據庫多實例節點訪問同一份數據，比如多個可讀寫實例、主備節點實例，訪問相同的數據；
- 分佈式存儲：應用表數據存儲在多個數據庫實例中，應用訪問存在跨多個數據庫節點
以上定義是從應用表數據的分佈形態出發，非傳統意義上數據最終存儲載體的定義。文中將簡要分析OceanBase、PolarDB、OpenGauss、GaussDB、GoldenDB、TiDB和TDSQL這幾個主流的國產數據庫的存儲類型及存儲引擎。
1.1 OceanBase數據庫
OceanBase是雲原生分佈式數據庫，具備高可用、可擴展、高度兼容Oracle和MySQL協議等特性。OceanBase數據庫採用Shared-Nothing架構（如下圖所示），各個節點之間完全對等，每個節點都有自己的SQL引擎、存儲引擎和事務引擎。
- OBProxy：OB數據庫代理ODP，負責接收用戶的SQL請求，結合請求中涉及數據的分佈，將用戶SQL請求轉發到最佳的OBServer節點上，在OBServer節點上執行完成後接受結果並將執行結果返回給用戶；
- OBServer：OB數據庫實例包含SQL引擎、事務引擎和存儲引擎，負責所在節點分區數據的讀取、路由到本機的SQL語句的解析和執行。
1.1.1 存儲層架構
在OB數據庫中，一個表的數據可以按照某種劃分規則水平拆分爲多個分片，每個分片叫做一個表分區，簡稱分區（Partition），其中某行數據屬於且只屬於一個分區。分區的規則由用戶在建表的時候指定，包括hash、range、list等類型的分區，還支持二級分區。一個表的若干個分區可以分佈在一個可用區內的多個節點上。每個物理分區有一個用於存儲數據的存儲層對象，叫做Tablet，用於存儲有序的數據記錄。
OceanBase數據庫的存儲引擎基於LSM-Tree架構，將數據分爲靜態基線數據（SSTable中）和動態增量數據（MemTable中）兩部分，其中SSTable是隻讀的，一旦生成就不再被修改，存儲於磁盤；MemTable支持讀寫，存儲於內存。數據庫DML操作插入、更新、刪除等首先寫入MemTable，等到MemTable達到一定大小時轉儲到磁盤成爲SSTable。在進行查詢時，需要分別對SSTable和MemTable進行查詢，並將查詢結果進行歸併，返回給SQL層歸併後的查詢結果。同時在內存實現了Block Cache和Row cache，來避免對基線數據的隨機讀。當內存的增量數據達到一定規模的時候，會觸發增量數據和基線數據的合併，把增量數據落盤。同時每天晚上的空閒時刻，系統也會自動每日合併。
在OB中，每個分區的基本存儲單元是一個個SSTable，而所有存儲的基本粒度是宏塊，數據文件按照2MB定長切分爲一個個宏塊，SSTable實際是多個宏塊的集合。
1.1.2 複製層架構
當用戶對Tablet中記錄進行修改的時候，爲了保證數據持久化，需要記錄重做日誌（REDO）到Tablet對應的日誌流（Log Stream）裏。日誌流代表一些數據的集合，包括若干Tablets和有序的Redo日誌流。在分佈式環境下，OB會將同一個日誌流數據拷貝到多個機器稱之爲副本，同一日誌流的多個副本使用Multi-Paxos一致性協議保證副本的強一致，每個日誌流和它的副本構成一個獨立的 Paxos 組，其中一個日誌流爲主副本（Leader），其它日誌流爲從副本（Follower）。主副本具備強一致性讀和寫能力，從副本具備弱一致性讀能力。
1.2 PolarDB數據庫
PolarDB數據庫是雲原生的數據庫產品，共有三個引擎，分別爲PolarDB MySQL版、PolarDB PostgreSQL版、PolarDB分佈式版。
1.2.1 PolarDB集中式架構
PolarDB集中式架構採用計算存儲分離的共享存儲架構，主節點和只讀節點使用物理複製、RDMA網絡低時延，能夠快速同步數據。基於存儲級別的複製解決了主從異步複製帶來的備庫數據一致性問題，保證數據庫集羣故障時候的數據零丟失。
- Proxy： 通過內部的代理層Proxy對外提供服務，應用程序的請求都先經過代理層，然後訪問到數據庫節點。代理層主要實現安全認證、保護和會話保持，SQL解析、讀寫操作分發以及實現讀寫分離功能。
- 計算節點：一寫多讀集羣內有一個讀寫節點以及多個只讀節點，多主集羣（僅MySQL版支持）內可支持多個讀寫節點和多個只讀節點，計算節點主要提供數據庫SQL引擎功能。
- 共享存儲：集羣內的多個節點共享存儲資源，單集羣支持最高100TB存儲空間。計算節點和存儲節點之間採用高速網絡互聯，並通過RDMA協議進行數據傳輸，保證I/O性能。
- 存儲數據多副本：存儲節點的數據採用多副本形式，確保數據的可靠性，並通過Parallel-Raft協議保證數據的一致性。
PolarDB數據庫採用存算分離的架構，計算節點僅存儲元數據，而將數據文件、Redo Log等存儲於遠端的存儲節點。各計算節點之間僅需同步Redo Log相關的元數據信息，極大地降低了主節點和只讀節點間的複製延遲，而且在主節點故障時，只讀節點可以快速切換爲主節點。
1.2.2 PolarDB分佈式架構
PolarDB分佈式版（PolarDB-X）採用了基於計算存儲分離的Share Nothing系統架構，具備高可用、高吞吐、大存儲、低時延和易擴展特性。
- 元數據服務（Global Meta Service，GMS）：主要提供分佈式的元數據，提供全局授時服務（TSO），維護Table/Schema、Statistic等Meta信息、維護賬號、權限等安全信息。
- 計算節點（Compute Node，CN）：主要提供分佈式SQL引擎，包含核心的優化器和執行器。基於無狀態的SQL引擎提供分佈式路由和計算，解決分佈式事務2PC協調、分佈式DDL執行、全局索引維護等。
- 存儲節點（Data Node，DN）：主要提供數據存儲引擎，基於多數派Paxos共識協議提供高可靠存儲、分佈式事務的MVCC多版本存儲，並提供分佈式計算下推能力，可支持本地盤和共享存儲。PolarDB-X的DN存儲節點是基於強一致數據庫X-DB構建，X-DB使用InnoDB引擎，兼容MySQL語法。
- 日誌節點（Change Data Capture，CDC）：主要兼容MySQL生態的主備複製協議，兼容Binlog協議和數據格式、支持主備複製Replication的協議和交互。通過PolarDB-X的CDC組件，提供與MySQL Binlog兼容的數據庫變更日誌，並提供給下游系統進行日誌的消費和訂閱。
1.3 OpenGauss數據庫
OpenGauss是華爲基於PostgreSQL內核開發的國產集中式數據庫系統，採用木蘭寬鬆許可證v2發行，具備高可靠、高性能、高安全、易運維和全開放等特性。和PostgreSQL數據庫相比，二者在底層架構和數據存儲方面類似，但OpenGauss在性能和擴展性方面進行了優化。
OpenGauss在部署架構上採用主備部署的模式，主備之間通過日誌同步方式實現數據同步。在邏輯架構上分爲管理模塊OM和CM、數據庫實例OpenGauss以及存儲節點：
- 運維管理模塊OM（Operation Manager）：提供數據庫日常運維、配置管理的管理接口、工具等
- 數據庫管理模塊CM（Cluster Manager）：管理和監控數據庫系統中各個功能單元和物理資源的運行情況，確保整個系統的穩定運行。CM提供數據庫主備的狀態監控、網絡通信故障監控、文件系統故障監控、故障自動主備切換等能力。
- OpenGauss實例：負責存儲業務數據、執行數據查詢任務以及向客戶端返回執行結果。在高可用架構下通常部署一主多備，並部署在不同的服務器上。
- 存儲Storage：服務器的本地存儲，用於數據持久化，支持集中式存儲
- 客戶端驅動：負責接收來自應用的訪問請求，並嚮應用返回執行結果。客戶端驅動負責與openGauss實例通信，發送應用的SQL命令，接收openGauss實例的執行結果。
其中CM支持兩種DN選主仲裁協議，兩種都適用於1主多備的集羣，1主1備的不適用
- Quorum 模式：基於多數派模式仲裁，選出同步備。當DN分片處於無主場景時，CM在多數派DN redo完成後，選擇term和lsn最大的節點(同步備)發送failover升主
- DCF（Distributed Consensus Framework）模式：基於Paxos協議的選主模式，該模式下DN自動選主，CM不再進行對DN選主，只負責數據採集，假死檢測等。
1.3.1 存儲層架構
OpenGauss支持可插拔的存儲引擎架構，在原生的存儲引擎基礎上新增了in-place update存儲引擎、索引多版本管理增加事務信息、內存表管理MOT。
1）In-place update存儲引擎（Ustore）
In-place Update存儲引擎（原地更新），是openGauss內核新增的一種存儲模式，在此前的版本使用的行存儲引擎是Append Update（追加更新Astore）模式。追加更新對於業務中的增、刪以及HOT（HeapOnly Tuple）Update（即同一頁面內更新）有很好的表現，但對於跨數據頁面的非HOT UPDATE場景，垃圾回收不夠高效。新增的In-place update存儲引擎旨在解決Append update存儲引擎空間膨脹和元組較大的問題，高效回滾段的設計是In-place update存儲引擎的基礎。
2）MOT內存優化存儲引擎
MOT存儲引擎是基於多核和大內存的服務器進行的優化，通過完全存儲在內存中的數據和索引、非統一內存訪問感知（NUMA-aware）設計、消除鎖和鎖存爭用的算法以及查詢原生編譯，MOT可提供更快的數據訪問和更高效的事務執行。
1.4 GaussDB數據庫
GaussDB數據庫（for openGauss）作爲企業級的分佈式數據庫，支持分佈式和主備的部署場景，其中分佈式版本包含CN（計算節點）、DN（數據存儲節點）和GTM（分佈式事務管理器）等節點類型。GaussDB數據庫的分佈式版本是基於share-nothing架構實現的，通過GTM-Lite技術實現事務強一致，消除了無中心節點性能的瓶頸。
GaussDB數據庫在數據庫組件上相比OpenGauss數據庫多了協調節點（Coordinator Node）和全局事務管理器（Global Transaction Manager），如下圖所示。
- OM（Operation Manager）：運維管理模塊提供數據庫日常運維、配置管理的管理接口、工具等
- CM（Cluster Manager）：數據庫管理模塊管理和監控數據庫系統中各個功能單元和物理資源的運行情況，確保整個系統的穩定運行。CM提供數據庫主備的狀態監控、網絡通信故障監控、文件系統故障監控、故障自動主備切換等能力。
- GTM（Global Transaction Manager）：全局事務管理器負責生成和維護全局事務ID、事務快照、時間戳和sequence等全局唯一的信息。
- CN（Coordinator Node）：協調節點負責接收來自應用的訪問請求，並向客戶端返回執行結果；負責對SQL請求解析，並將請求路由到不同的DN分片上執行。
- DN（Data Node）：數據節點負責存儲業務數據、執行數據查詢任務以及向CN或客戶端返回執行結果
- ETCD：分佈式鍵值存儲系統，用於共享配置和服務發現
- CMS（cm_server）：進行數據庫實例管理和實例仲裁的組件。主要功能包括：1）接收各個節點上cm_agent發送的數據庫各實例狀態；2）提供數據庫實例整體狀態的查詢功能；3）監控實例的狀態變化並進行仲裁命令的下發
- Storage：服務器的本地存儲，用於數據持久化，支持集中式存儲
1.4.1 GaussDB存儲引擎
存儲引擎向上對接SQL引擎，爲SQL引擎提供或接收標準化的數據格式（元組或向量數組）；存儲引擎向下對接存儲介質，按照特定的數據組織方式，以頁面、壓縮單元（Compress Unit）或其他形式爲單位，通過存儲介質提供的特定接口，對存儲介質中的數據完成讀、寫操作。
GaussDB存儲引擎包括行存引擎和列存引擎以及MOT內存引擎，行存引擎主要面向TP類業務、列存引擎主要面向AP類業務。行存引擎對於讀寫併發操作，採用多版本併發控制（MVCC，Multi-Version Concurrency Control）；對於寫寫併發操作，採用基於兩階段鎖協議（2PL，Two-Phase Locking）的悲觀併發控制（PCC，Pessimistic Concurrency Control）。
1.5 GoldenDB數據庫
GoldenDB分佈式數據庫是基於分佈式中間件的分庫分表架構，該架構將數據分成不同的分片，每個分片又存儲在不同的存儲節點，且單個分片是主備複製架構以保證高可用。業務請求經過數據庫中間件（計算節點）解析和路由分發到不同的數據分片，實現分佈式功能。同時通過全局事務協調節點來保證事務的全局一致性。GoldenDB數據庫在整體架構上由由計算節點、數據節點、全局事務管理器、管理節點四種核心模塊組成。
- 計算節點CN：負責SQL優化、SQL路由、數據節點的負載均衡、分佈式事務調度等；
- 數據節點DN：數據存儲節點，每個數據節點對應一個MySQL實例，多個數據節點組成一個DBGroup；
- 全局事務節點GTM：用於協助計算節點進行分佈式事務管理，主要包括全局事務ID（GTID）的生成和釋放、維護活躍事務列表以及當前活躍事務的快照。GTM包括集羣級別的GTM和租戶級別的GTM，租戶級別只用於當前租戶、集羣級別是整個集羣共用；
- 管理節點：包括數據庫運維管理平臺Insight、元數據管理模塊MDS、數據庫集羣管理模塊CM和計算節點集羣管理模塊PM。
GoldenDB分佈式數據庫支持多租戶管理模式、架構上支持橫向動態擴展和節點擴縮容，提供讀寫分離策略。主備節點之間採用快同步方式同步複製，並採用gSync技術提高同步性能，滿足金融級別的高可用要求。GoldenDB數據庫的存儲節點是基於MySQL數據庫的，內核存儲引擎上使用的是InnoDB引擎。
1.6 TiDB數據庫
TiDB是開源雲原生分佈式關係型數據庫，採用存儲和計算分離的架構、提供行列存儲引擎支持HTAP混合型業務、基於Multi-Raft多數派協議實現多副本之間數據同步，滿足金融級別的高可用要求。TiDB兼容MySQL協議和MySQL生態，並提供多種數據遷移工具實現MySQL應用平滑遷移到TiDB。
TiDB分佈式數據庫將整體架構拆分成了多個模塊，各模塊之間互相通信，組成完整的TiDB系統。對應的架構圖如下：
- TiDB Server：SQL層負責接受客戶端的連接、執行SQL解析和優化，最終生成分佈式執行計劃。TiDB Server本身是無狀態的，通過負載均衡組件對外提供統一的接入地址。
- PD（Placement Driver）：TiDB集羣的元數據管理模塊，是整個集羣的“大腦”，負責存儲每個TiKV節點實時的數據分佈情況和集羣的整體拓撲結構，提供TiDB Dashboard管控界面，併爲分佈式事務分配事務ID。
- TiKV Server：分佈式key-value存儲節點，存儲數據的基本單位是Region，每個Region負責存儲一個Key Range的數據，每個TiKV節點會負責多個Region。
- TiFlash：列式存儲引擎的存儲節點，主要用於AP型的業務場景。
1.6.1 RocksDB存儲引擎
RocksDB是由Facebook基於LevelDB開發的一款提供key-value存儲與讀寫功能的LSM-tree架構引擎。RocksDB適用於多CPU場景、高效利用fast storage比如SSD、彈性擴展架構、支持IO-bound/in-memory/write-once等功能。
RocksDB不是一個分佈式的DB，而是一個高效、高性能、單點的數據庫引擎。RocksDB持久化存儲key-value鍵值對數據，keys和values可以是任意的字節流，且按照keys以log-structured merge tree的形式有序存儲。
上圖就是Rocksdb的基礎架構，主要完成以下功能：
- Rocksdb中引入了ColumnFamily(列族,CF)的概念，所謂列族也就是一系列kv組成的數據集。所有的讀寫操作都需要先指定列族。
- 寫操作先寫WAL，再寫memtable，memtable達到一定閾值後切換爲Immutable Memtable，只能讀不能寫。
- 後臺Flush線程負責按照時間順序將Immu Memtable刷盤，生成level0層的有序文件(SST)。
- SST又分爲多層（默認至多6層），每一層的數據達到一定閾值後會挑選一部分SST合併到下一層，每一層的數據是上一層的10倍（因此90%的數據存儲在最後一層）。
- Manifest負責記錄系統某個時刻SST文件的視圖，Current文件記錄當前最新的Manifest文件名。
- 每個ColumnFamily有自己的Memtable，SST文件，所有ColumnFamily共享WAL、Current、Manifest文件。
RocksDB作爲TiKV的核心存儲引擎，用於存儲Raft日誌以及用戶數據。每個TiKV實例中有兩個RocksDB實例，一個用於存儲Raft日誌（通常被稱爲raftdb），另一個用於存儲用戶數據以及MVCC信息（通常被稱爲kvdb）。kvdb中有四個ColumnFamily：raft、lock、default和write：
- raft列：用於存儲各個Region的元信息，僅佔極少量空間
- lock列：用於存儲悲觀事務的悲觀鎖以及分佈式事務的一階段Prewrite鎖。當用戶的事務提交之後， lock cf中對應的數據會很快刪除掉，因此大部分情況下lock cf中的數據也很少（少於1GB）。如果lock cf中的數據大量增加，說明有大量事務等待提交，系統出現了bug或者故障。
- write列：用於存儲用戶真實的寫入數據以及MVCC信息（該數據所屬事務的開始時間以及提交時間）。當用戶寫入了一行數據時，如果該行數據長度小於255字節，那麼會被存儲write列中，否則的話該行數據會被存入到default列中。由於TiDB的非unique 索引存儲的value爲空，unique索引存儲的value爲主鍵索引，因此二級索引只會佔用writecf的空間。
- default列：用於存儲超過255字節長度的數據
1.6.2 TiKV中的Raft算法
TiKV使用Raft算法來保證數據的一致性，默認情況下使用3副本組成一個raft group，過Raft的日誌複製功能，將數據安全可靠地同步到raft group的每一個節點中。
- 當client端需要寫數據的時候，它會發送請求給Raft Leader，Leader會將操作解碼爲log entry並以append方式寫入自己的Raft log中
- Leader會根據Raft算法將log entry複製到Follower，Follower也會將這些entry追加到log entry中，並且通知Leader已經完成
- 當Leader發現log entry追加到多數majority節點中，它會認爲這個log entry已經committed。之後Leader會解碼entry中的操作，執行它們並應用到狀態機中，這個過程稱之爲apply
另外，TiKV支持lease Read功能：對於讀請求，可以直接發送給Leader，如果leader判斷基於時間的lease沒有過期，則可以直接提供讀請求的客戶端，不需要經過Raft算法過程；如果過期了，則leader需要強制通過Raft算法來更新lease內容提供該客戶端。
1.7 TDSQL數據庫
TDSQL（for MySQL）分佈式數據庫基於Shared Nothing架構和分佈式中間件將數據拆分到多個物理分片節點上，支持自動水平拆分、主備同步複製滿足金融級別高可用要求。TDSQL分佈式數據庫採用存算分離的架構，採用多租戶的模式支持集中式和分佈式實例部署、X86和ARM服務器混合部署。主要包括以下功能模塊：
- 數據庫存儲層：由數據庫節點組（SET）組成，SET是邏輯概念，由一組物理設備或虛擬化節點構成
- SET存儲數據庫核心數據，採用主從高可用（HA）架構，節點數通常≥2，根據業務實際需求可擴展
- 每個節點（Node）信息採集與管理模塊（Agent），互相檢測心跳以確保集羣的健壯性
- 數據庫計算層：是由SQL引擎（SQL-Engine）組成，又稱爲Proxy。計算層既要管理客戶端的長短連接，還要處理複雜的SQL語句進行彙總計算，屬於CPU密集型高內存消耗的組件。
- Proxy是無狀態的，本身不存儲數據，也沒有主備之分可以同時與業務系統通訊。Proxy節點數通常≥2，根據業務實際需求進行動態擴展，並且前端需要部署負責均衡保證節點之前負載均衡。
- Proxy層存儲和處理數據庫元數據，負責語法和語義解析。在分佈式場景下，還需要處理分佈式事務、維護全局自增字段、分佈式SQL語句的下推和匯聚等。
- 配置管理決策調度集羣，是由Zookeeper、Scheduler、Manager等組件組成。集羣管理調度組件滿足多數派選舉通常需要奇數臺，以基於raft協議實現對實例高可用切換的第三方選舉。
- GTM（Metacluster）：提供分佈式事務全局一致性的事務管理器，主要由Metacluster中心時鐘源爲事務的開啓、提交階段提供一個全局唯一且嚴格遞增的事務時間戳以及事務管理器（TM）組成，爲了提高併發效率TM模塊目前內置於計算層。
- 運維支撐系統，是由OSS運營調度管理模塊、監控採集與分析模塊、赤兔管理系統組成。
以上組件共同構成了TDSQL分佈式數據庫的整體架構，實現分佈式實例和集中式實例在數據庫集羣中的混合部署，並提供了擴展性、高可用性以及運維功能支持。
1.7.1 存儲引擎
TDSQL for MySQL提供不同的存儲引擎，包括InnoDB版本和TDStore版本。InnoDB版本是採用InnoDB作爲數據庫存儲引擎，也是MySQL默認的存儲引擎；TDStore版本是騰訊雲自研的敏態存儲引擎，兼容MySQL標準協議，專爲適配金融級敏態業務而設計。
TDStore引擎採用存儲和計算分離的結構，包括計算節點、存儲節點和管控節點，計算層和存儲層的節點均可根據業務需求獨立彈性擴縮容。TDStore存儲層基於LSM-Tree + SSTable結構存放和管理數據，具有較高的壓縮率，能有效降低海量數據規模下的存儲成本。對比InnoDB存儲引擎，TDStore版最高可實現高達20倍的壓縮率，單實例可支撐EB級別的存儲量。
1.7.2 主備節點同步複製
由於MySQL原生的主備節點之間的半同步複製技術存在異步退化、relay log無法保證實時落盤以及等待Slave返回ACK工作線程處於阻塞狀態等問題，TXSQL對主備節點的同步複製進行了優化：
- Master等待Slave ACK超時時，返回給客戶端失敗，不會退化爲異步複製，保證了主備數據的強一致性；
- 採用組提交的方式，增加rpl_slave_ack_thread線程，循環取出io thread接收到的binlog name和pos等信息，且只處理最後一個；
- 採用線程池+業務線程異步化，在Master等待Slave ACK的過程中將會話保存起來，然後線程切換到其他的會話處理，不用無謂的等待；
TXSQL的強同步機制，主機等待至少一個備機應答成功後才返回客戶端成功，保證了數據的一致性，滿足金融級的高可用要求。同時採用並行多線程和組提交技術，大幅提升主備複製的性能。
如上圖所示客戶端寫請求提交後，線程池分配連接處理請求，但是並沒有立即返回給客戶端，而是將這部分信息保存在內存會話信息中。Master發起主備同步請求，接收備機收到binlog的ACK請求，當接收到備機日誌落盤的ACK返回後，主節點的工作線程喚起剛剛保存的會話，執行後半段的提交操作，並將結果返回給客戶端。因此在Master節點開啓了兩組線程：接收備機ACK應答線程（Dump ACK Thread）和喚醒hang住的客戶端連接線程（User ACK Thread）。
1.8 各數據庫存儲類型對比
以上數據庫從架構類型上分爲集中式和分佈式，集中式架構包括PolarDB和openGauss、分佈式架構包括OceanBase、PolarDB-X版本、GaussDB、GoldenDB、TiDB和TDSQL。其中在存儲類型、存儲類型和高可用協議上各不相同：
- 存儲類型：PolarDB使用的是主備節點集中式存儲、openGauss則是本地存儲模式，主備節點是不同的存儲；OceanBase和TiDB是嚴格意義上的分佈式存儲，而GaussDB、GoldenDB和TDSQL從應用角度是表數據分佈在不同的實例，只是這個分片按照實例的維度，不是原生分佈式按照更小的region維度。
- 存儲引擎：OceanBase數據庫是基於LSM-tree存儲引擎、TiDB基於RocksDB引擎、PolarDB、GoldenDB和TDSQL都是基於InnoDB存儲引擎，只是TDSQL又自研了TDStore存儲引擎。OpenGauss和GaussDB都是基於PostgreSQL內核自研出UStore和MOT內存引擎。
- 高可用：副本的高可用算法，OceanBase、PolarDB-X、OpenGauss和GaussDB都支持Paxos協議、TiDB是基於Multi-Raft協議實現的、GoldenDB和TDSQL則是主備節點複製、PolarDB由於是集中式存儲，通過存儲級別的複製保證了高可用性。
參考資料：
- https://www.oceanbase.com/docs
- https://help.aliyun.com/zh/polardb
- https://docs-opengauss.osinfra.cn/zh/docs/5.0.0/docs
- https://support.huaweicloud.com/fg-gaussdb-dist/gaussdb-18-0144.html
- https://www.goldendb.com/#/docsIndex
- https://docs.pingcap.com/zh/tidb/stable/overview
- https://cloud.tencent.com/document/product/557
微信公衆號
