剛哥談架構 （九） 開源關係型數據庫架構

我之前跟大家分享了數據庫架構（剛哥談架構 （五） 談談數據庫架構），今天我們來討論一下數據庫中最爲常見的關係型數據庫的架構。

我們把主要的開源關係型數據庫分爲三類，來分別瞭解一下它們的架構和設計，並瞭解一下它們各自的優缺點。

• OLTP，在線事務處理，是傳統的關係型數據庫的主要應用場景
• OLAP，在線分析處理，是當今大數據，數據倉庫使用的主要的數據庫技術
• SQL Query Engine，隨着存算分離技術的發展，SQL查詢引擎也佔據了開源關係型數據庫的重要的位置

 

 

---

OLTP

OLTP是在線事務處理，在3層體系結構中支持面向事務的應用程序。 OLTP管理組織的日常事務。主要目標是數據處理而不是數據分析。

OLTP的主要特點是：

• 大量的短時間交易請求和處理
• 對信息進行增刪改查的操作，常常需要查詢明細信息。
• 必須保證事務和數據的一致性
• 通常要支持大量的併發用戶

下面我們就來看看主要的開源OLTP的數據庫架構。

 

MySQL

MySQL是最爲流行的開源關係數據庫

 

MySQL採用了經典的客戶端服務器C/S架構，服務器端的主要組件包含：

• 連接池，處理連接和認證授權
• SQL接口，語法解析，優化器，緩存
• 可插拔的存儲引擎，支持InnoDB、MyISAM、Memory等多個存儲引擎。
• 物理文件，包含redolog、undolog、binlog、errorlog、querylog、slowlog、data、index等
• 服務工具，備份，安全等

MySQL架構設計中的一些關鍵技術包括：

• 利用緩存來避免提高熱數據的查詢性能
• 利用優化器優化查詢性能
• 例如redo log/bin log避免頻繁寫數據庫帶來的性能壓力。同時在出錯的時候可以通過日誌來恢復
• 通過兩階段提交來保證兩份日誌的一致性

MySQL支持事務，事務是一組原子性的SQL查詢，或者說一個獨立的工作單元。事務的ACID:

• 原子性(atomicty)：一個不可分割的最小工作單元。
• 一致性(consistency)：數據庫總是從一個一致性狀態轉換到另一個一致性的狀態。
• 隔離性(isolation)：一個事務所做的修改在最終提交以前，對其他事務是不可見的。
• 持久性(durability)：事務提交後，其所做的修改會永久保存到數據庫中。(沒有100%的持久性持久性保證策略)

MySQL的大多數存儲引擎通過數據快照的形式支持了多版本的併發控制。

優點：

• 性能卓越服務穩定，很少出現異常宕機
• 開放源代碼且無版權制約，自主性強。
• 歷史悠久、社區及用戶非常活躍，遇到問題，可以很快獲取到幫助。
• 支持多種操作系統，提供多種 API 接口，支持多種開發語言。
• 體積小、速度快、易於維護，安裝及維護成本低。
• MySql的核心程序採用完全的多線程編程。線程是輕量級的進程，它可以靈活地爲用戶提供服務，而不過多的系統資源。用多線程和C語言實現的MySql能很容易充分利用CPU。
• 擁有一個非常快速而且穩定的基於線程的內存分配系統，可以持續使用面不必擔心其穩定性。

缺點：

• MySQL的設計是用來支持事務的OLTP數據庫，本身缺乏支持水平擴展的能力。對於水平擴展更多是通過分庫，分表加上客戶端的處理來支持的。
• 不支持熱備份。
• 安全管理系統比較簡單。
• 不允許調試存儲過程，開發和維護存儲過程很難。

開源的MySQL集羣軟件比較少，例如Myat。而官方的MySQL Cluster不是開源的，它是將線性可伸縮性和高可用性結合在一起的分佈式數據庫。它提供了跨分區和分佈式數據集的事務內一致性的內存實時訪問。

 

因爲MySQL被“邪惡”的Oracle收購，社區另開門戶，以MySQL的代碼創建分支，開發了MariaDB。MariaDB Server是最受歡迎的開源關係數據庫之一。它由MySQL的原始開發人員製作，並保證保持開源。它是大多數雲產品的一部分，並且是大多數Linux發行版中的默認產品。

書籍推薦：

 

 

 

PostgreSQL

PostgreSQL是一個功能強大的開源對象關係數據庫系統，經過30多年的積極開發，在可靠性，功能強大和性能方面贏得了極高的聲譽。

 

PostgreSQL和MySQL一樣使用客戶端/服務器模型。

PostgreSQL會話由以下協作過程（程序）組成：

• 服務器進程管理數據庫文件，接受來自客戶端應用程序的數據庫連接，並代表客戶端執行數據庫操作。PostgreSQL服務器可以處理來自客戶端的多個併發連接。爲此，它爲每個連接啓動（“分叉”）新過程。從那時起，客戶端和新服務器進程進行通信，而無需原始postgres進程進行干預。因此，主服務器進程始終在運行，等待客戶端連接，而客戶端和關聯的服務器進程來來往往。
• 想要執行數據庫操作的客戶端（前端）應用程序。客戶端應用程序的性質可能非常多樣：客戶端可以是面向文本的工具，圖形應用程序，訪問數據庫以顯示網頁的Web服務器或專用的數據庫維護工具。

PostgreSQL的物理結構非常簡單。它由共享內存以及一些後臺進程和數據文件組成。

共享內存

共享內存是指爲數據庫緩存和事務日誌緩存保留的內存。共享內存中最重要的元素是共享緩衝區和WAL緩衝區

共享緩衝區
共享緩衝區的目的是使DISK IO最小化。爲此，必須滿足以下原則

• 需要快速訪問非常大的緩衝區（數十，數百GB）。
• 當許多用戶同時訪問爭用時，應將爭用最小化。
• 常用塊必須在緩衝區中保留儘可能長的時間

WAL緩衝區

• • WAL緩衝區是一個臨時將更改存儲到數據庫的緩衝區。將WAL緩衝區中存儲的內容在預定的時間點寫入WAL文件。從備份和恢復的角度來看，WAL緩衝區和WAL文件非常重要。

PostgreSQL有四種進程類型。

• 守護程序進程
  守護進程是啓動PostgreSQL時啓動的第一個進程。在啓動時，執行恢復，初始化共享內存並運行後臺進程。當客戶端進程發出連接請求時，它還會創建一個後端進程。
• 後臺進程
  Logger將錯誤消息寫入日誌文件。
  Checkpointer發生檢查點時，髒緩衝區將被寫入文件。
  Writer定期將髒緩衝區寫入文件。
  WAL writer將WAL緩衝區寫入WAL文件。
  Autovacuum launcher將分叉自動真空工作程序.autovacuum守護程序負責按需對桌面進行真空操作
  Archiver在Archive.log模式下，將WAL文件複製到指定目錄。
  統計收集器統計數據庫使用統計信息。
• 後端進程進行數據處理工作。後端進程執行用戶進程的查詢請求，然後發送結果。執行查詢需要一些內存結構，稱爲本地內存。

• 客戶進程
  客戶端進程是指爲每個後端用戶連接分配的後臺進程。通常，守護進程將派生一個專門爲用戶連接服務的子進程。

PostgreSQL希望做到單棧全功能數據庫，包括：

• OLTP：事務處理是PostgreSQL的本行
• OLAP：citus分佈式插件，ANSI SQL兼容，窗口函數，CTE，CUBE等高級分析功能，任意語言寫UDF流處理：PipelineDB擴展，Notify-Listen，物化視圖，規則系統，靈活的存儲過程與函數編寫
• 時序數據：timescaledb時序數據庫插件，分區表，BRIN索引
• 空間數據：PostGIS擴展（殺手鐗），內建的幾何類型支持，GiST索引。
• 搜索索引：全文搜索索引足以應對簡單場景；豐富的索引類型，支持函數索引，條件索引
• NoSQL：JSON，JSONB，XML，HStore原生支持，至NoSQL數據庫的外部數據包裝器
• 數據倉庫：能平滑遷移至同屬Pg生態的GreenPlum，DeepGreen，HAWK等，使用FDW進行ETL
• 圖數據：遞歸查詢

優點：

• 支持更豐富的數據類型的存儲，包括Array，JSON等。支持R-Tree索引的樹狀結構。
• 豐富的SQL編程能力，支持遞歸，有非常豐富的統計函數和統計語法支持
• 外部數據源支持，可以多種外部數據源 (包括 Mysql, Oracle, CSV, hadoop …) 當成自己數據庫中的表來查詢
• 無限長 TEXT 類型，支持全文搜索和正則搜索
• 支持圖數據格式的存儲
• 豐富的索引類型支持，支持 B-樹、哈希、R-樹和 Gist 索引
• 較好的穩定性和平穩的性能
• 可以做到同步，異步，半同步複製，以及基於日誌邏輯複製，可以實現表級別的訂閱和發佈。
• 支持各種分佈式集羣部署
  PostgreSQL有豐富的開源cluster軟件支持。plproxy 可以支持語句級的鏡像或分片，slony 可以進行字段級的同步設置，standby 可以構建WAL文件級或流式的讀寫分離集羣，同步頻率和集羣策略調整方便，操作非常簡單。Postgres-X2是一個開放源代碼項目，可提供水平可伸縮性，包括寫可伸縮性，同步多主機和透明PostgreSQL接口。它是緊密耦合的數據庫組件的集合，可以安裝在多個硬件或虛擬機中。

缺點：

• PostgreSQL的 MVCC 事務語義依賴於能夠比較事務 ID（XID）數字：如果一個新版本的插入 XID 大於當前事務的 XID，它就是"屬於未來的"並且不應該對當前事務可見。XID的問題可能會導致長時間停機的故障。
• Failover故障可能會丟失數據，如果運行中的主服務器突然出現故障，那麼運行中的流複製設置幾乎肯定會丟失已提交的數據。
• 物理複製有利有弊，低效率的複製會傳播失敗。使用物理複製，大型索引構建會創建大量WAL條目，從而很容易成爲流複製的瓶頸。
• MVCC垃圾回收頻發。與大多數主流數據庫一樣，PostgreSQL使用多版本併發控制（MVCC）來實現併發事務。但是，其特定的實現通常會給垃圾行的數據版本及其清理（VACUUM）帶來操作上的麻煩
• 每次連接處理=規模化痛苦，PostgreSQL爲每個連接生成一個進程，而其他大多數數據庫都使用更有效的連接併發模型。由於存在一個相對較低的閾值，在該閾值上添加更多的連接會降低性能（約2個內核），最終會導致性能下降

和MySQL相比較，PostgreSQL從底層設計原理不盡相同，在數據量小的時候，數據庫更趨於輕量化，MySQL會更適合。但是一旦數據量大的時候，應用場景複雜，或者需要分析的場合，PostgreSQL會是更好的選擇。

書籍推薦：

 

 

 

CockroachDB

CockroachDB是爲現代雲應用程序設計的分佈式數據庫。它與PostgreSQL兼容，並由一個RocksDB或專門創建的派生工具Pebble的鍵值存儲提供支持。

CockroachDB 思路源自 Google 的全球性分佈式數據庫 Spanner。CockroachDB 既具有 NoSQL 對海量數據的存儲管理能力，又保持了傳統數據庫支持的 ACID 和 SQL 等，還支持跨地域、去中心、高併發、多副本強一致和高可用等特性。支持 OLTP 場景，同時支持輕量級 OLAP 場景。

CockroachDB主要設計目標是可擴展，強一致和高可用 。CockroachDB旨在無人爲干預情況下，以極短的中斷時間容忍磁盤、主機、機架甚至整個數據中心的故障 。 CockroachDB採用完全去中心化架構，集羣中各個節點的地位完全對等，同時所有功能封裝在一個二進制文件中，可以做到儘量不依賴配置文件直接部署

 

Node代表一個CockroachDB進程實例，一般情況下一臺物理機部署一個CockroachDB實例，一個CockroachDB實例可以配置多個Store, 單個Store與RocksDB實例一一對應，一般情況下一個Store對應一塊物理磁盤。CockroachDB按照範圍進行數據切分，最小數據切分單元是Range。Range默認的配置大小是64M, 以3副本的方式分佈在各個節點上，副本間通過Raft協議進行數據同步。

CockroachDB底層是RocksDB的KV，在此之上，利用Raft協議來實現分佈式的多副本的一致性。節點故障無丟失數據風險。CockroachDB架構上去中心化，沒有單點故障：架構不存在集中式模塊，單節點故障不影響集羣整體的可用性。基於Raft協議，只要半數以上副本存活，則服務可用；當節點異常，數據副本數量少於指定閾值時，自動補齊副本；基於HLC分佈式時鐘同步算法，任意節點皆可充當事務管理節點，無中心事務管理器。

CockroachDB使用Gossip協議實現節點狀態管理，理論上單集羣支持10K節點規模。

CockroachDB兼容PostgreSQL協議，對於報文的封裝和解析完全按照PostgreSQL的方式進行，所以用戶可以直接使用PostgreSQL的客戶端訪問CockroachDB。

優點：

• 支持標準SQL，兼容PostgreSQL
• 擴展能力強，高併發，支持彈性擴容和高可用。單集羣支持10K節點的規模, 能夠存儲的數據最大爲4EB
• 支持分佈式事務，多副本強一致。支持多區域部署
• CRDB所有功能都在一個編譯好的二進制中, 不需要依賴其它組件, 運維部署都非常方便.

缺點：

• 相對比較新，社區和生態還不成熟
• 修改了代碼授權協議，不再是開源友好。CockroachDB 的核心代碼授權協議將採用 BSL。用戶可以將 CockroachDB 擴展到任意數量的節點，可以隨意使用 CockroachDB，也可以將其嵌入到應用程序中（無論是將這些應用程序發送給客戶，還是將其作爲服務運行），甚至可以在內部將 CockroachDB 作爲服務運行。唯一不能做的事情是，在沒有購買許可證的情況下，提供商業版 CockroachDB 作爲服務。

 

TiDB

TiDB是支持MySQL語法的開源分佈式混合事務/分析處理（HTAP）數據庫。TiDB可以提供水平可擴展性、強一致性和高可用性。它主要由PingCAP公司開發和支持，並在Apache 2.0下授權。TiDB從Google的Spanner和F1論文中汲取了最初的設計靈感。

TiDB是國產數據庫的翹楚，所屬公司 PingCAP於11月宣佈完成D輪2.7億美元融資，創造了全球數據庫歷史新的里程碑。到目前爲止，PingCAP 總計已融資 3.416 億美元，上一次的 5000 萬美元 C 輪融資於2018年9月完成。截止到2020年10月，TiDB項目在GitHub上已總計獲得超過25000顆星，近1200位開源代碼貢獻者，參與企業包括美團、知乎、伴魚、豐巢、小米、微衆銀行、UCloud、Zoom、Samsung、Square、PayPay 等行業企業。

HTAP 是 Hybrid Transactional / Analytical Processing 的縮寫。這個詞彙在 2014 年由 Gartner 提出。傳統意義上，數據庫往往專爲交易或者分析場景設計，因而數據平臺往往需要被切分爲 TP 和 AP 兩個部分，而數據需要從交易庫複製到分析型數據庫以便快速響應分析查詢。而新型的 HTAP 數據庫則可以同時承擔交易和分析兩種智能，這大大簡化了數據平臺的建設，也能讓用戶使用更新鮮的數據進行分析。作爲一款優秀的 HTAP 數據數據庫，TiDB 除了優異的交易處理能力，也具備了良好的分析能力。

TiDB在整體架構基本是參考 Google Spanner 和 F1 的設計，上分兩層爲 TiDB 和 TiKV 。 TiDB 對應的是 Google F1， 是一層無狀態的 SQL Layer ，兼容絕大多數 MySQL 語法，對外暴露 MySQL 網絡協議，負責解析用戶的 SQL 語句，生成分佈式的 Query Plan，翻譯成底層 Key Value 操作發送給 TiKV ， TiKV 是真正的存儲數據的地方，對應的是 Google Spanner ，是一個分佈式 Key Value 數據庫，支持彈性水平擴展，自動的災難恢復和故障轉移（高可用），以及 ACID 跨行事務。值得一提的是 TiKV 並不像 HBase 或者 BigTable 那樣依賴底層的分佈式文件系統，在性能和靈活性上能更好，這個對於在線業務來說是非常重要。

 

• TiDB Server：SQL 層，對外暴露 MySQL 協議的連接 endpoint，負責接受客戶端的連接，執行 SQL 解析和優化，最終生成分佈式執行計劃。TiDB 層本身是無狀態的，實踐中可以啓動多個 TiDB 實例，通過負載均衡組件（如 LVS、HAProxy 或 F5）對外提供統一的接入地址，客戶端的連接可以均勻地分攤在多個 TiDB 實例上以達到負載均衡的效果。TiDB Server 本身並不存儲數據，只是解析 SQL，將實際的數據讀取請求轉發給底層的存儲節點 TiKV（或 TiFlash）。
• PD (Placement Driver) Server：整個 TiDB 集羣的元信息管理模塊，負責存儲每個 TiKV 節點實時的數據分佈情況和集羣的整體拓撲結構，提供 TiDB Dashboard 管控界面，併爲分佈式事務分配事務 ID。PD 不僅存儲元信息，同時還會根據 TiKV 節點實時上報的數據分佈狀態，下發數據調度命令給具體的 TiKV 節點，可以說是整個集羣的“大腦”。此外，PD 本身也是由至少 3 個節點構成，擁有高可用的能力。建議部署奇數個 PD 節點。
• 存儲節點

• • TiKV Server：負責存儲數據，從外部看 TiKV 是一個分佈式的提供事務的 Key-Value 存儲引擎。存儲數據的基本單位是 Region，每個 Region 負責存儲一個 Key Range（從 StartKey 到 EndKey 的左閉右開區間）的數據，每個 TiKV 節點會負責多個 Region。TiKV 的 API 在 KV 鍵值對層面提供對分佈式事務的原生支持，默認提供了 SI (Snapshot Isolation) 的隔離級別，這也是 TiDB 在 SQL 層面支持分佈式事務的核心。TiDB 的 SQL 層做完 SQL 解析後，會將 SQL 的執行計劃轉換爲對 TiKV API 的實際調用。所以，數據都存儲在 TiKV 中。另外，TiKV 中的數據都會自動維護多副本（默認爲三副本），天然支持高可用和自動故障轉移。
  • TiFlash：TiFlash 是一類特殊的存儲節點。和普通 TiKV 節點不一樣的是，在 TiFlash 內部，數據是以列式的形式進行存儲，主要的功能是爲分析型的場景加速。

和CockroachDB採用了類似的架構設計，TiKV實際上也是基於RocksDB，同樣採用了Raft協議來實現分佈式的一致性。值得一提的是TiKV用Rust語言開發，是開源社區的網紅明星。

 

優點：

• 純分佈式架構，擁有良好的擴展性，支持彈性的擴縮容
• 支持 SQL，對外暴露 MySQL 的網絡協議，併兼容大多數 MySQL 的語法，在大多數場景下可以直接替換 MySQL
• 默認支持高可用，在少數副本失效的情況下，數據庫本身能夠自動進行數據修復和故障轉移，對業務透明
• 支持 ACID 事務，對於一些有強一致需求的場景友好，例如：銀行轉賬
• 具有豐富的工具鏈生態，覆蓋數據遷移、同步、備份等多種場景
• 智能的行列混合模式，TiDB 可經由優化器自主選擇行列。這套選擇的邏輯與選擇索引類似：優化器根據統計信息估算讀取數據的規模，並對比選擇列存與行存訪問開銷，做出最優選擇。

缺點：

• 雖然兼容MySQL，但是不支持存儲過程，觸發器，自定義函數，窗口功能有限。
• 不適用數據量小的場景，專門爲大數據量設計。

 

SQLite

SQLite是一種C語言庫，可實現小型，快速，自包含，高可靠性，功能齊全的SQL數據庫引擎。 SQLite是世界上最常用的進程內，嵌入式數據庫引擎。 SQLite內置在所有手機和大多數計算機中，並捆綁在人們每天使用的無數其他應用程序中。

SQLite因爲其特點，無法應用與海量數據的場景。

 

OpenGauss

openGauss 是華爲開源關係型數據庫管理系統，採用木蘭寬鬆許可證 v2 發行。openGauss 內核源自 PostgreSQL，深度融合華爲在數據庫領域多年的經驗，結合企業級場景需求，持續構建競爭力特性。同時 openGauss 也是一個開源的數據庫平臺，鼓勵社區貢獻、合作。

OpenGauss因爲起步時間短，社區還不成熟，這裏就不做詳細介紹了。

 

總結

MySQL是最爲流行的開源OLTP數據庫，有非常強大的生態。

PostgeSQL支持豐富的功能和擴展性，能應用與各種不同的場景中。

CockroachDB和TiDB同樣借鑑了google spanner的架構，底層使用RocksDB作爲KV存儲，使用raft協議保證分佈式的一致性來實現高可用和高擴展，是新一代開源OLTP的代表。

雖然PostgreSQL和TiDB都號稱能兼顧OLTP和OLAP的場景，但是我還是把它們都歸於OLTP的分類。他們的核心設計都更適合TP的場景。

SQLite是小型的關係型數據庫，可用於進程內的部署。

 

---

OLAP

OLAP（Online Analytical Processing）聯機分析處理，是指一類軟件工具，可爲業務決策提供數據分析。 OLAP系統允許用戶一次分析來自多個數據庫系統的數據庫信息。主要目標是數據分析而不是數據處理。

OLAP的主要特點是：

• 數據量通常比較大
• 大部分操作是Select
• 數據一致性不是非常的關鍵
• 以讀操作爲主，很少更新
• 併發查詢的量通常不會很大

下面我們就來看看主要的開源OLAP的數據庫架構。

 

Apache Hive

Hive是基於Hadoop的用於查詢和管理大型分佈式數據集的數據倉庫軟件。Apache Hive數據倉庫軟件有助於使用SQL讀取，寫入和管理駐留在分佈式存儲中的大型數據集。可以將結構投影到已經存儲的數據上。提供了命令行工具和JDBC驅動程序以將用戶連接到Hive。

Hadoop的出現，通過HDFS和Map/Reduce解決了海量數據的存儲和計算問題，然而Map/Reduce並不是一個開發者友好的計算和編程接口。Hive的出現解決了這個問題，基於Hadoop，Hive提供一個用戶友好的SQL接口，對海量數據進行操作。

 

 

從架構上來看，Hive包含：

• 客戶端，Hue，Qubole，CLI等
• 通過Thrift Server，提供JDBC/ODBC連接
• Driver，所有命令和查詢都轉到驅動程序，該驅動程序通常使用MapReduce作業來編譯輸入，優化所需的計算並執行所需的步驟。
• Metastore是一個單獨的關係數據庫（通常是一個MySQL實例），保存Hive的表模式和其他系統元數據
• 底層是Hadoop的文件系統和計算節點

Hive不提供的某係數據庫功能，例如行級更新，快速的查詢響應時間和事務，這時候你可能會需要HBase，HBase是一種分佈式且可擴展的數據存儲，它支持行級更新，快速查詢和行級事務（但不支持多行事務）。 HBase是一個開源的非關係型分佈式數據庫，它參考了谷歌的BigTable建模，實現的編程語言爲Java。它是Apache軟件基金會的Hadoop項目的一部分，運行於HDFS文件系統之上，爲 Hadoop 提供類似於BigTable 規模的服務。因此，它可以對稀疏文件提供極高的容錯率。

Hive是查詢引擎，而HBase是專門用於非結構化數據的數據存儲。Apache Hive主要用於批處理（即OLAP），但HBase廣泛用於事務處理，其中查詢的響應時間不是高度交互的，即OLTP。與Hive不同，HBase中的操作在數據庫上實時運行，而不是轉換爲mapreduce作業。HBase用於實時查詢，Hive用於分析查詢。

Hive採用了Schema On Read的模式，當通過加載外部數據，寫入查詢的輸出，執行UPDATE語句等將數據寫入傳統數據庫時，數據庫可以完全控制存儲。該數據庫是“守門人”。數據庫可以在寫入數據時強制執行模式。這被稱爲Schema on write。Hive無法控制基礎存儲。有多種方法可以創建，修改甚至破壞Hive將要查詢的數據。因此，Hive只能在讀取時強制執行查詢。這稱爲讀取模式Schema on read。如果模式與文件內容不匹配怎麼辦？ Hive盡其所能讀取數據。如果記錄中沒有足夠的字段來匹配模式，那麼將獲得很多空值。如果某些字段是數字，並且Hive遇到非數字字符串，它將爲這些字段返回null。最重要的是，Hive會盡力從所有錯誤中恢復。

Hive除了支持Map/Reduce作爲計算引擎，也可以使用SparkSQL作爲計算引擎。當然SparkSQL也可以脫離Hive，使用其它數據存儲來支持SQL查詢。這是一種典型的存算分離的數據處理技術。

優點：

• Hive在海量數據上支持了OLAP場景下的分析查詢
• Hive支持水平擴展，高可靠，高容錯
• Hive支持Map/Recude或者Spark作爲計算引擎

缺點

• 效率不高，延遲較高，默認的M/R執行引擎啓動有延遲
• 不支持物理化視圖，不能在視圖上更新、插入、刪除
• 不適用OLTP，暫不支持列級別添加、更新、刪除
• 暫不支持存儲過程，當前版本不支持存儲過程
• HiveQL的表達能力有限

書籍推薦：

 

Greenplum

建立在PostgreSQL上的分析數據庫平臺。全名是Pivotal Greenplum數據庫。一個用於分析，機器學習和AI的開源大規模並行數據平臺

• MPP體系結構，PB級加載，Greenplum的所有主要貢獻都是Greenplum數據庫項目的一部分，並且共享相同的數據庫核心，包括MPP體系結構，分析接口和安全功能。
• 聯合數據訪問，使用Greenplum優化器和查詢處理引擎查詢外部數據源。包括Hadoop，雲存儲，ORC，AVRO，Parquet和其他Polyglot數據存儲。
• 多態數據存儲，完全控制表和分區存儲，執行和壓縮的配置。根據訪問數據的方式設計表。用戶可以選擇任何表或分區的行或列導向存儲和處理。
• 集成的數據庫內分析，使用Apache MADlib處理數據科學，從實驗到大規模部署，Apache MADlib是Postgres系列數據庫的集羣內機器學習功能的開源庫。具有Greenplum的MADlib提供了多節點，多GPU和深度學習功能。
• 查詢優化方面的創新，Greenplum數據庫中提供的查詢優化器是業界第一個針對大數據工作負載而設計的基於開源成本的查詢優化器。它可以將交互式和批處理模式分析擴展到PB級的大型數據集，而不會降低查詢性能和吞吐量。

Greenplum數據庫是基於PostgreSQL開源技術的。它本質上是多個PostgreSQL面向磁盤的數據庫實例一起工作形成的一個緊密結合的數據庫管理系統（DBMS）

Greenplum數據庫和PostgreSQL的主要區別在於：

• 在基於Postgres查詢規劃器的常規查詢規劃器之外，可以利用GPORCA進行查詢規劃。
• Greenplum數據庫可以使用追加優化的存儲。
• Greenplum數據庫可以選用列式存儲，數據在邏輯上還是組織成一個表，但其中的行和列在物理上是存儲在一種面向列的格式中，而不是存儲成行。列式存儲只能和追加優化表一起使用。列式存儲是可壓縮的。當用戶只需要返回感興趣的列時，列式存儲可以提供更好的性能。所有的壓縮算法都可以用在行式或者列式存儲的表上，但是行程編碼（RLE）壓縮只能用於列式存儲的表。Greenplum數據庫在所有使用列式存儲的追加優化表上都提供了壓縮。

 

Greenplum的最小並行單元不是節點層級，而是在實例層級，每個實例都有自己的postgresql目錄結構，都有各自的一套Postgresql數據庫守護進程（甚至可以通過UT模式進行單個實例的訪問）。正因爲如此，甚至一個運行在單節點上的GreenplumDB也是一個小型的並行計算架構，一般一個節點配置6~8個實例，相當於在一個節點上有6~8個Postgresql數據庫同時並行工作，優勢在於可以充分利用到每個節點的所有CPU和IO 能力。

優點：

• 採用無共享(no shareing)的MPP架構；具有良好的線性擴展能力，具有高效的並行運算、並行存儲特性。
• 擁有獨特的高效的ORCA優化器。
• 兼容SQL語法。適合用於高效PB數據量級的存儲、處理和實時分析能力。
• 由於內核是基於PostgreSQL數據庫；也支持涵蓋OLTP型業務混合負載。
• 同時數據節點和主節點都有自己備份節點。提供數據庫的高可用性。

缺點：

• 併發能力很有限（受物理Master限制），性能隨併發量增加而快速下降。Master主控節點性能瓶頸，併發性能低，實際應用中無法支持超過30個併發。
• 主從雙層架構，並非真正的扁平架構，存在性能瓶頸和SPOF單點故障。集羣規模受物理Master限制，實際應用中很難超過20個物理節點。
• 無法支持數據壓縮態下的DML操作，不易於數據的維護和更新。
• 主備雙Master節點容災方案，在切換事物日誌到備用master時，如有數據操作，容易導致數據損壞、insert數據丟失、delete未刪除成功等。
• 單個節點上的數據庫沒有並行和大內存使用能力，必須通過部署多個實列（segment servers）來充分利用系統資源，造成使用和部署很複雜。

 

Clickhouse

俄羅斯搜索巨頭Yandex開發的面向列存的關係型數據庫。ClickHouse是過去兩年中OLAP領域中最熱門的，並於2016年開源。典型的用戶包括著名的公司，例如字節，新浪和騰訊。

ClickHouse是基於MPP架構的分佈式ROLAP（關係OLAP）分析引擎。每個節點都有同等的責任，並負責部分數據處理（不共享任何內容）。ClickHouse 是一個真正的列式數據庫管理系統（DBMS)。在 ClickHouse 中，數據始終是按列存儲的，包括矢量（向量或列塊）執行的過程。只要有可能，操作都是基於矢量進行分派的，而不是單個的值它開發了矢量化執行引擎，該引擎使用日誌合併樹，稀疏索引和CPU功能（如SIMD單指令多數據）充分發揮了硬件優勢，可實現高效的計算。因此，當ClickHouse面臨大數據量計算方案時，通常可以達到CPU性能的極限。

通常有兩種不同的加速查詢處理的方法：矢量化查詢執行和運行時代碼生成。在後者中，動態地爲每一類查詢生成代碼，消除了間接分派和動態分派。這兩種方法中，並沒有哪一種嚴格地比另一種好。運行時代碼生成可以更好地將多個操作融合在一起，從而充分利用 CPU 執行單元和流水線。矢量化查詢執行不是特別實用，因爲它涉及必須寫到緩存並讀回的臨時向量。如果 L2 緩存容納不下臨時數據，那麼這將成爲一個問題。但矢量化查詢執行更容易利用 CPU 的 SIMD 功能。將兩種方法結合起來是更好的選擇。ClickHouse 使用了矢量化查詢執行，同時初步提供了有限的運行時動態代碼生成。

列式存儲和數據壓縮，對於一款高性能數據庫來說是必不可少的特性。如果你想讓查詢變得更快，最簡單且有效的方法是減少數據掃描範圍和數據傳輸時的大小，而列式存儲和數據壓縮就可以幫助實現上述兩點。列式存儲和數據壓縮通常是伴生的，因爲一般來說列式存儲是數據壓縮的前提。ClickHouse數據按列進行組織，屬於同一列的數據會被保存在一起，列與列之間也會由不同的文件分別保存 。數據默認使用LZ4算法壓縮，在Yandex.Metrica的生產環境中，數據總體的壓縮比可以達到8:1 ( 未壓縮前17PB，壓縮後2PB )。列式存儲除了降低IO和存儲的壓力之外，還爲向量化執行做好了鋪墊。

ClickHouse用C ++編寫，具有一個獨立的系統，幾乎不依賴第三方工具。支持相對完整的DDL和DML。大多數操作可以通過結合SQL的命令行來完成；分佈式集羣依賴Zookeper管理，並且單個節點不需要依賴Zookeper。大多數配置都需要通過修改配置文件來完成。

 

ClickHouse通常要求用戶在創建表結構時指定分區列。採用數據壓縮和純列存儲技術，使用Mergetree分別存儲每列並壓縮塊，同時，數據將始終以碎片的形式寫入磁盤。當滿足某些條件時，ClickHouse將通過後臺線程定期合併這些數據片段。當數據量繼續增加時，ClickHouse將合併分區目錄中的數據，以提高數據掃描的效率。

同時，ClickHouse爲每個數據塊提供了一個稀疏索引。處理查詢請求時，稀疏索引可用於減少數據掃描並加快速度。

 

Clickhouse最初架構是基於MySQL實現的，所以在ClickHouse的設計中，能夠察覺到一些MySQL的影子，表引擎的設計就是其中之一。與MySQL類似，ClickHouse也將存儲部分進行了抽象，把存儲引擎作爲一層獨立的接口。ClickHouse共擁有合併樹、內存、文件、接口和其他6大類20多種表引擎。其中每一種表引擎都有着各自的特點，用戶可以根據實際業務場景的要求，選擇合適的表引擎使用。

優點：

• 性能卓越。在成本與性能之間做到了良好平衡，即快又開源。即便是在複雜查詢的場景下，它也能夠做到極快響應，且無須對數據進行任何預處理加工。
• 數據壓縮比高，存儲成本低。
• 支持常用的SQL語法，寫入速度非常快，適用於大量的數據更新。

缺點：

• 不適合高併發的場景。在ClickHouse官方網站文檔中，建議ClickHouse的併發數量不超過100。當併發要求較高時，爲了減少ClickHouse的資源消耗，可以結合ClickHouse的某些特殊引擎對其進行優化。
• 分佈式管理較爲薄弱，使得運營、使用成本偏高。
• ClickHouse 集羣自身雖然可以方便的水平增加節點，但並不支持自動的數據均衡。在節點故障的情況下，ClickHouse 並不會利用其它機器補齊缺失的副本數據。需要用戶先補齊節點後，然後系統再自動在副本間進行數據同步。
• ClickHouse 在單表性能方面表現非常出色，但是在複雜場景仍有不足，缺乏成熟的 MPP 計算引擎和執行優化器。例如：多表關聯查詢、複雜嵌套子查詢等場景下查詢性能一般，需要人工優化; 缺乏 UDF 等能力，在複雜需求下擴展能力較弱等。
• ClickHouse 並不適合實時寫入，原因在於 ClickHouse 並非典型的 LSM Tree 架構，它沒有實現 Memory Table 結構，每批次寫入直接落盤作爲一棵 Tree(如果單批次過大，會拆分爲多棵 Tree)，每條記錄實時寫入會導致底層大量的小文件，影響查詢性能。這使得 ClickHouse 不適合有實時寫入需求的業務，通常需要在業務和 ClickHouse 之間引入一層數據緩存層，實現批量寫入。

 

Apache Druid

https://druid.apache.org/

Apache Druid是開源分析數據庫，專爲對高維度和高基數數據進行亞秒級OLAP查詢而設計，它由廣告分析公司Metamarkets創建，到目前爲止，已被許多公司使用，包括Airbnb，Netflix，Nielsen，eBay，Paypal和Yahoo。它結合了OLAP數據庫，時間序列數據庫和搜索系統的思想，以創建適用於廣泛使用案例的統一系統。最初，Apache Druid在2012年獲得GPL許可，成爲開源軟件，此後在2015年更改爲Apache 2許可，並於2018年加入Apache Software Foundation作爲孵化項目。

Druid提供OLAP查詢的主要功能包括：

• 爲了提高存儲效率和在數據範圍內進行快速過濾，Druid以面向列的壓縮格式存儲數據。因此，它可以處理數據冗餘，同時使用高效的格式對多維聚合和分組執行查詢。要回答查詢，它僅加載所需的確切列。每列都針對其特定數據類型進行了優化存儲。爲了在多個列之間提供快速過濾和搜索，Druid使用了最新的壓縮位圖索引（。
• 任何數據源（即Druid中的表）的架構都非常靈活，可以輕鬆地進行開發。
• 數據是根據時間進行分區的，因此時間序列查詢的速度明顯快於傳統數據庫。
• Druid提供了開箱即用的算法，用於近似計數差異，近似排名以及近似直方圖和分位數的計算。
• 它具有高度的可擴展性，已用於每秒每秒數百萬個事件和多年數據存儲的生產環境中。
• 查詢的平均響應時間以秒爲單位。
• 容錯架構。
• 與最新的大數據技術集成，包括Apache Kafka，Apache Flink，Apache Spark和Apache Hive。
• 提供基於本機JSON的語言，以及基於HTTP或JDBC的SQL（實驗性）。
• 提供高級商業智能和分析數據探索和可視化工具（如Metabase和Apache Superset）支持。

 

Druid平臺依賴於以下三個外部依賴項：

• 深度存儲：它可以是任何分佈式文件系統或對象存儲，例如Amazon S3，Azure Blob存儲，Apache HDFS（或任何HDFS兼容系統）或網絡安裝的文件系統。深度存儲的目的是持久保存Druid吸收的所有數據，作爲備份解決方案，並在需要時同時可供所有Druid組件和羣集使用。
• 元數據存儲：由傳統的關係數據庫系統（例如PostgreSQL或MySQL）支持。所有元數據都可用於任何Druid組件。 Druid中有多種類型的元數據，有些與深度存儲中的持久段有關，例如段文件的路徑，它們的時間戳，它們的版本等，其他可能與外部系統有關，例如從Apache提取分區偏移量Kafka主題以及其餘主題與各種內部流程的元數據有關（例如，現在正在其中創建段）。
• ZooKeeper：用於內部服務發現，協調和領導者選舉。

Druid的體系結構由以下處理類型的組件組成：

• 中間管理器進程（Middle Manager）處理將數據提取到羣集中的過程。例如，他們負責從Apache Kafka攝取實時流數據或從其他來源加載一批數據（例如，來自HDFS的文件）。
• 歷史進程（Historical）處理“歷史”數據的存儲和查詢。運行歷史進程的節點將從深度存儲中獲取分段到其本地磁盤，並響應有關這些分段的查詢。
• 代理進程（Broker）從外部客戶端接收查詢。它們確定哪個歷史記錄和中間管理器節點正在服務那些段，並將重寫的子查詢發送到這些流程中的每個流程。此後，他們收集併合並結果並響應呼叫者。在內部，歷史記錄進程會響應與已保留到深度存儲中的數據段相對應的子查詢，而中級代理將響應與最近提取的數據。
• 爲了在歷史和中間管理器流程之間平衡數據，Druid分別具有協調器流程和Overload流程。具體地說，協調器進程負責將段分配給正在運行歷史記錄進程的特定節點。同樣，Overlord流程負責將提取任務分配給中間管理器進程，並負責協調細分發布。
• 最後，路由器進程在Brokers，Overlords和Coordinator的前面提供了一個統一的API網關。它們的使用是可選的，因爲還可以直接聯繫Brokers，Overlords和Coordinator。

如前所述，Druid由用於攝取，查詢和協調的獨立組件組成。每個Druid流程組件都可以獨立配置和擴展，從而提供最大的靈活性，並具有強大的容錯能力（因爲一個組件的故障不會立即影響其他組件）。此外，將深度存儲和元數據存儲與Druid系統的其餘部分分開，可以從一直保留在深度和元數據存儲中的數據中重新啓動組件或整個集羣。

優點：

• 亞秒級的OLAP查詢分析，Druid採用了列式存儲/倒排索引/位圖索引等關鍵技術,能夠在亞秒級別內完成海量數據的過濾/聚合以及多位分析等操作
• 高可用性和高擴展性，Druid採用分佈式,SN(share-nothing)架構,管理類節點課配置HA,工作節點功能單一,不互相依賴,耦合性低,各種節點掛掉都不會使Druid停止工作
• 實時流數據分析。區別於傳統分析型數據庫採用的批量導入數據進行分析的方式，Druid提供了實時流數據分析，採用LSM(Long structure merge)-Tree結構使Druid擁有極高的實時寫入性能

缺點：

• 數據不可修改，數據沒有 update 更新操作，只對 segment 粒度進行覆蓋：由於時序化數據的特點，Druid 不支持數據的更新。
• 能接受的數據的格式相對簡單，比如不能處理嵌套結構的數據
• Druid 查詢併發有限，不適合 OLTP 查詢。
• 不支持Join 操作：Druid 適合處理星型模型的數據，不支持關聯操作。

 

Apache Kylin

Apache Kylin是用於大數據的分佈式分析引擎，提供SQL接口和多維分析（OLAP）並可用於用Hadoop棧。它最初由eBay中國研發中心開發，於2014年開源併爲Apache Software Foundation貢獻力量，具有亞秒級的查詢功能和超高的併發查詢功能，被美團，滴滴，攜程，殼牌，騰訊，58.com等許多主要製造商採用。

Kylin是基於Hadoop的MOLAP（多維OLAP）技術。核心技術是OLAP Cube;與傳統的MOLAP技術不同，Kylin在Hadoop上運行，Hadoop是一個功能強大且可擴展的平臺，可以支持大量（TB到PB）數據。它將預先計算（由MapReduce或Spark執行）的多維多維數據集導入到低延遲分佈式數據庫HBase中，以實現亞秒級的查詢響應。最近的Kylin 4開始使用Spark + Parquet代替HBase來進一步簡化架構。由於在脫機任務（多維數據集構造）過程中已完成大量聚合計算，因此在執行SQL查詢時，它不需要訪問原始數據，而是直接使用索引來組合聚合結果並再次進行計算。性能高於原始數據。一百甚至數千次；由於CPU使用率低，它可以支持更高的併發性，特別適合於自助服務分析，固定報告和其他多用戶交互式分析方案。

Kylin用Java編寫，完全集成到Hadoop生態系統中，並使用HDFS進行分佈式存儲。計算引擎可以是MapReduce，Spark和Flink。存儲引擎可以是HBase，Parquet（與Spark結合使用）。源數據訪問支持Hive，Kafka，RDBMS等，多節點協調依賴Zookeeper；與Hive元數據兼容，Kylin僅支持SELECT查詢，Schema修改需要在Hive中完成，然後同步到Kylin；傳遞建模和其他操作Web UI完成，通過Rest API執行任務調度，並且可以在Web UI上查看任務進度。

Kylin使用Hadoop生態系統HBase或Parquet作爲存儲結構，依靠HBase的行鍵索引或Parquet的行組稀疏索引來提高查詢速度，並使用HBase Region Server或Spark執行器進行分佈式並行計算。Kylin通過預聚合計算多維Cube數據，並在查詢時根據查詢條件動態選擇最佳Cuboid（類似於實例化視圖），這將大大減少CPU計算和IO讀取的數量。在多維數據集構建過程中，Kylin對維值進行某些編碼和壓縮，例如字典編碼，以最大程度地減少數據存儲；由於Kylin的存儲引擎和架構引擎是可插拔的，因此也存在用於不同存儲引擎的存儲結構。

Kylin的核心原則是預先計算，利用空間換時間來加速查詢：Kylin的計算引擎使用Apache Spark和MapReduce；存儲使用HBase和Parquet；SQL分析和後計算使用Apache Calcite。Kylin的核心技術是開發一系列優化方法，以幫助解決尺寸爆炸和掃描數據過多的問題。這些方法包括：設置聚合組，設置維度尺寸，設置派生維度，設置維度錶快照，設置行鍵順序，按列設置分片等。

 

Kylin 利用 MapReduce/Spark 將原始數據進行聚合計算，轉成了 OLAP Cube 並加載到 HBase 中，以 Key-Value 的形式存儲。Cube 按照時間範圍劃分爲多個 segment，每個 segment 是一張 HBase 表，每張表會根據數據大小切分成多個 region。Kylin 選擇 HBase 作爲存儲引擎，是因爲 HBase 具有延遲低，容量大，使用廣泛，API完備等特性，此外它的 Hadoop 接口完善，用戶社區也十分活躍。

優點：

• 基於預計算，數據量愈大，優勢越大。
• SQL接口，Kylin主要的對外接口就是以SQL的形式提供的。SQL簡單易用的特性極大地降低了Kylin的學習成本，不論是數據分析師還是Web開發程序員都能從中收益。
• 支持海量數據集。不論是Hive、SparkSQL，還是Impala、Presto，都改變不了這樣一個事實：查詢時間隨着數據量的增長而線性增長。而Apache Kylin使用預計算技術打破了這一點。Kylin在數據集規模上的侷限性主要取決於維度的個數和基數，而不是數據集的大小，所以Kylin能更好地支持海量數據集的查詢。
• 亞秒級響應，同樣受益於預計算技術，Kylin的查詢速度非常快，因爲複雜的連接、聚合等操作都在Cube的構建過程中已經完成了。
• 水平擴展，Apache Kylin同樣可以使用集羣部署方式進行水平擴展。但部署多個節點只能提高Kylin處理查詢的能力，而不能提升它的預計算能力。
• 可視化集成，Apache Kylin提供了ODBC/JDBC接口和RESTful API，可以很方便地與Tableau等數據可視化工具集成。數據團隊也可以在開放的API上進行二次開發。

缺點：

• 不支持明細查詢
• 預計算會佔用大量空間，也存在維度爆炸的問題
• 靈活性差

 

Apache Doris

Doris是用於報告和分析的基於MPP的交互式SQL數據倉庫。它的原始名稱是在百度開發時的Palo。捐贈給Apache Software Foundation之後，它更名爲Doris。

Doris是一個MPP的ROLAP系統，主要整合了Google Mesa（數據模型），Apache Impala（MPP Query Engine)和Apache ORCFile (存儲格式，編碼和壓縮) 的技術。

Doris定位爲：

• MPP 架構的關係型分析數據庫
• PB 級別大數據集，秒級/毫秒級查詢
• 主要用於多維分析和報表查詢

 

Doris 的整體架構和 TiDB 類似，藉助 MySQL 協議，用戶使用任意 MySQL 的 ODBC/JDBC以及MySQL 的客戶端，都可以直接訪問 Doris。Doris 中的模塊包括 FE 和 BE 兩類：FE 主要負責元數據的管理、存儲，以及查詢的解析等；一個用戶請求經過 FE 解析、規劃後，具體的執行計劃會發送給 BE，BE 則會完成查詢的具體執行。BE 節點主要負責數據的存儲、以及查詢計劃的執行。目前平臺的 FE 部分主要使用 Java，BE 部分主要使用 C++。

Doris的主要設計思路有：

• 按列存儲，支持數據壓縮，減少磁盤IO
• 向量化執行，是列存數據庫特有的一個優化技巧，可以減少CPU消耗，提升CPU利用率。
• Doris 沒有一個強索引，它只有一個稀疏索引，當稀疏索引滿足不了用戶的場景通過支持物化視圖來加速。
• 元數據層面，Doris 採用 Paxos 協議以及 Memory + Checkpoint + Journal 的機制來確保元數據的高性能及高可靠。

優點：

• 數據高可靠，在服務器宕機的情況下，服務依然可用，數據也不會丟失
• 易運維，Doris 部署無外部依賴，只需要部署 BE 和 IBE 即可搭建起一個集羣。
• 支持 Online Schema Change
• 類似TiDB，兼容MySQL

缺點：

• 社區剛剛起步，生態還不成熟

 

總結

Apache Hive是基於Hadoop的數據倉庫解決方案，但是查詢性能一般。

Greenplum是基於PostgreSQL開發的MPP架構的開源OLAP解決方案。

Clickhouse是最近最爲流行的OLAP開源工具，主要採用了列存，向量化，Mergetree等技術，性能不是一般的強。

Apache Kylin是基於Hadoop的MOLAP，主要採用了預匯聚來實現海量數據的查詢性能。

Apache Druid是開源時序OLAP工具，支持高可用可高擴展。Druid也採用了預匯聚的技術。

Apache Doris是百度開源的基於MPP的交互式SQL數據倉庫，同樣利用了列存和向量化技術，使用Paxos協議實現分佈式的一致性。

 

---

SQL Query Engine

存算分離是現代數據庫區別於傳統數據庫的主要特點之一，主要是爲了

• 提升資源利用效率，用戶用多少資源就給多少資源；
• 計算節點無狀態更有利於數據庫服務的高可用性和集羣管理（故障恢復、實例遷移）的便利性。

存算分離的架構特別適合雲上的部署，能夠分別擴展存儲和計算資源，做到資源和成本的最大利用和收益。

存算分離後，計算側就需要一個與存儲分離的SQL 查詢引擎，常見的開源SQL查詢引擎有Facebook的Presto，Apache Drill和SparkSQL。

 

Presto

Presto是一個適用於大數據的分佈式SQL查詢引擎，使SQL可以訪問任何數據源。可以使用Presto通過水平縮放查詢處理來查詢非常大的數據集。Presto用於對大小從GB到PB的各種數據源運行交互式分析查詢。Presto是專爲交互式分析而設計和編寫的，可在擴展到Facebook之類的組織規模的同時，實現商業數據倉庫的速度。

雖然Presto理解並可以有效執行SQL，但是Presto不是數據庫，因爲它不包括自己的數據存儲系統。它並不是要成爲通用的關係數據庫。Presto並非設計爲處理OLTP的場景。

Presto利用衆所周知的技術和新穎的技術來進行分佈式查詢處理。這些技術包括

• 內存中並行處理，集羣中跨節點的流水線執行，
• 使所有CPU核心保持繁忙的多線程執行模型，
• 有效的平面內存數據結構
• 最小化Java垃圾收集
• Java字節碼生成

Presto可以應用在許多的場景下。

 

Presto是一個分佈式SQL查詢引擎，類似於大規模並行處理（MPP）樣式的數據庫和查詢引擎。除了依賴於運行Presto的服務器的垂直擴展，它還能夠以水平方式在服務器集羣中分佈所有處理能力。這意味着可以通過添加更多節點來獲得更多處理能力。

 

Presto的架構主要包含：

• 客戶端
• 協調器是Presto服務器，它處理傳入的查詢並管理工作程序以執行查詢。包含解析分析器，計劃器，調度器
• Worker是Presto服務器，負責執行任務和處理數據。
• Discovery Service發現服務通常在協調器上運行，並允許工作人員進行註冊以加入集羣。

Presto存儲與計算分離的核心是基於連接器的體系結構。連接器爲Presto提供了訪問任意數據源的接口。連接器的API稱爲SPI（service provider interface ）。

 

優點：

• 類似SparkSQL的SQL計算引擎，全部計算在內存內完成，性能有優勢
• 支持的數據源的種類非常多
• 支持聯邦查詢

缺點：

• 雖然能夠處理PB級別的海量數據分析，但不是代表Presto把PB級別都放在內存中計算的。而是根據場景，如count，avg等聚合運算，是邊讀數據邊計算，再清內存，再讀數據再計算，這種耗的內存並不高。但是連表查，就可能產生大量的臨時數據，因此速度會變慢，反而Hive此時會更擅長。
• 爲了達到實時查詢，可能會想到用它直連MySql來操作查詢，這效率並不會提升，瓶頸依然在MySql，此時還引入網絡瓶頸，所以會比原本直接操作數據庫要慢。
• 沒有容錯設計，當某個任務失敗時，整個查詢都會失敗
• 因爲查詢都在內存中，內存不夠會導致查詢失敗

書籍推薦：

 

Apache Drill

適用於Hadoop，NoSQL和雲存儲的無模式SQL查詢引擎。

 

Apache Drill類似SparkSQL和Presto，Apache Drill可以在不同的數據源上執行SQL查詢， 它是一個低延遲的大型數據集的分佈式查詢引擎，包括結構化和半結構化數據/嵌套。其靈感來自於谷歌的 Dremel，Drill 的設計規模爲上千臺節點並且能與 BI 或分析環境互動查詢。在大型數據集上，Drill 還可以用於短，交互式的臨時查詢。Drill 能夠用於嵌套查詢，像 JSON 格式，Parquet 格式以及動態的執行查詢。Drill 不需要一個集中的元數據倉庫。

Apache Drill 的核心服務是 “Drillbit”，她負責接受來自客戶端的請求，處理請求，並返回結果給客戶端。Drillbit 服務能夠安裝在並運行在 Hadoop 集羣上。當 Drillbit 運行在集羣的每個數據節點上時，能夠最大化去執行查詢而不需要網絡或是節點之間移動數據。Drill 使用 ZooKeeper 來維護集羣的健康狀態。雖然 Drill 工作於 Hadoop 集羣環境下，但是 Drill 不依賴 Hadoop，並且可以運行在任何分佈式集羣環境下。唯一的先決條件就是需要 ZooKeeper。

 

Drill的查詢性能主要靠以下幾點設計來支持：

• Drill基於列式存儲數據，類似Spark和Presto，計算在內存內進行，避免了磁盤IO
• 使用代碼生成，把SQL轉化爲物理執行計劃，Drillbit的operator再將其生成爲Java代碼，本地代碼生成避免了代碼分發（Spark）的問題
• 長久存活的Drillbit。基於YARN的資源分配模式需要創建和銷燬Java進程，Spark可以一定程度上利用Executor的重用來減少JVM的開銷。Drill的Drillbit是一直存活的，避免了創建和銷燬帶來的開銷。

優點：

• 動態Schema發現，在開始執行查詢處理的時候，Drill 不需要爲規範數據的 Schema 和類型。Drill 開始處理數據是在記錄批處理的時候，在處理過程中去發現 Schema。
• 靈活的數據模型，Drill 允許數據屬性嵌套。從架構的角度來看，Drill 提供了靈活的柱狀數據模型，她能夠呈現複雜的，高動態的和不斷變化的數據模型。關係型數據在 Drill 中能夠被轉化爲特殊的或是複雜/半結構化的數據。
• Drill 沒有集中式的元數據要求。你不需要創建和管理表和視圖
• 擴展性好，Drill 提供了一個可擴展的體系結構，包括存儲插件，查詢，查詢優化/執行，以及客戶端接口層

缺點：

• 長久存活的Drillbit導致缺乏資源的隔離，如果一個Query佔用過多資源，會導致其它Query無法獲得資源。
• 安裝和部署比較麻煩
• 垃圾回收是個問題

書籍推薦：

 

SparkSQL

Spark SQL是Apache Spark的用於處理結構化數據的模塊。

• 將SQL查詢與Spark程序無縫混合。Spark SQL可以使用SQL或熟悉的DataFrame API在Spark程序中查詢結構化數據。可在Java，Scala，Python和R中使用。
• 統一數據訪問，以相同的方式連接到任何數據源。DataFrame和SQL提供了一種訪問各種數據源的通用方法，包括Hive，Avro，Parquet，ORC，JSON和JDBC。甚至可以跨這些源連接數據。
• Hive整合，在現有倉庫上運行SQL或HiveQL查詢。Spark SQL支持HiveQL語法以及UDF，從而可以訪問現有的Hive倉庫。
• 標準連接，通過JDBC或ODBC連接。服務器模式爲商業智能工具提供了行業標準的JDBC和ODBC連接。
• 性能與可擴展性，Spark SQL包括基於成本的優化器，列存儲和代碼生成，以加快查詢速度。同時，使用Spark引擎可擴展到數千個節點和數小時的查詢，該引擎可提供完整的中查詢容錯能力。不必擔心爲歷史數據使用其他引擎。

 

優點：

• 靈活，Spark SQL將SQL查詢與Spark程序混合使用，藉助Spark SQL，我們可以查詢結構化數據作爲分佈式數據集（RDD），我們可以使用Spark SQL運行SQL查詢以及複雜的分析算法。
• 高兼容性，在Spark SQL中，我們可以在現有數據倉庫上運行未經修改的Hive查詢。Spark SQL完全兼容現有的Hive數據、查詢和UDF。
• 統一數據訪問，使用Spark SQL，我們可以加載和查詢來自不同來源的數據。Schema-RDD允許使用單一接口高效地處理結構化數據，例如Apache Hive表、parquet文件和JSON文件。
• 性能優化，Spark SQL中的查詢優化引擎將每個SQL查詢轉換爲邏輯計劃，然後轉換爲許多物理執行計劃，最後它選擇最優化的物理執行計劃。

缺點：

• 不支持的union類型，使用Spark SQL，不能創建或讀取包含聯合字段的表。
• 不支持事務

書籍推薦：

 

 

總結

作爲SQL查詢引擎，SparkSQL是最爲流行的，Spark是分佈式內存內計算引擎，常被用來取代Map/Reduce做大數據的計算平臺，SparkSQL可以用於對結構化數據進行SQL的運算，非常方便。而Presto利用其插件的設計，除了用於SQL計算，還經常被用於SQL的聯邦查詢，不需要把數據移動到本地存儲。Apache Drill的應用不如前兩者廣泛。

---

 

好了，因爲開源數據庫這塊的東西實在是太多了，這裏我拋磚引玉，給大家一個參考，希望能對大家選用數據庫技術有所幫助。