TiDb

^{數據庫中間件的優缺點}

優點：

缺點：

• 只適用於簡單業務，同時對業務有侵入性，需要改造業務
• 很難支撐跨分片的高性能復雜查詢
• 分布式事務性能損失，一般是在單機的事務之上增加一層分布式事務（如事務管理器,TCC）
• 水平擴展能力差，只能按照選定的分配規則橫向擴展
• 大型集群運維困難
• 表結構變更(DDL)操作困難，容易出現失誤
• 只能按照分片進行維護（備份、恢復等操作）

^{NoSQL Not Only SQL}

• 放棄高級SQL能力，追求強水平擴展能力（反過來意味着業務兼容的成本高）
  • 　　放棄復雜SQL查詢
  • 　　放棄分布式事務（ACID）
• 通常的數據訪問模型：
  • 　　鍵值對
  • 　　文檔型
• 代表系統：
  • 　　mongoDB
  • 　　CouchBase
  • 　　Cassandra
  • 　　HBase

 典型系統分析：MongoDB

1. 文檔型數據庫
2. 仍然是通過選擇Sharing key的方式進行分片
   • 　　Range或hash分片
3. 優點：
   • 　　Scheme-less，對文檔型數據比較友好
4. 缺點：

• • 跨分片聚合能力差
  • rebalance過程中會占用大量帶寬
  • 無跨分片事務

 典型系統分析：HBase

1. Google BigTable的開源實現
2. 擴展能力構建在分布式文件系統（HDFS）之上
3. 分布式表格系統
4. 優點：
   
   • 依賴HDFS的橫向擴展能力，基本可以做到無限的水平擴展
   • Region Server用於管理數據分片
   1. 1. 支持動態水平切分
      2. 初步做到熱點轉移
5. 缺點：
   • 無事務支持
   • 依賴HDFS提供存儲能力，多一層抽象，性能損失
   • Hadoop體系運維復雜度高

 典型系統分析：Cassandra

1. Amazon Dynamo論文實現
2. 分布式KV數據庫
3. 優點：
   • 提供在單KV操作上的多種一致性模型
   • 強一致 or 最終一致性 可配置
   • 並不是ACID事務
   • 擴展性強
4. 缺點
   
   1. KV模型過於簡單，對業務侵入性大
   2. 運維比較復雜
   3. 國內社區和支持缺乏

NoSQL系統的通用優缺點

優點：

1. 水平擴展能力強
2. 針對特殊類型數據效果好，可以作為關系型數據庫的很好補充
3. 對於一致性要求不強的場景，可能會有更好的性能

缺點：

1. 由於不支持SQL業務需要進行較大的改造
2. 普遍無法支持事務，強一致性場景比較難實現
3. 復雜查詢受限

第三代分布式數據庫NewSQL

兩種流派：

• 以Google Spanner為代表的Shared Nothing架構
• 以AWS Aurora為代表的Shared Everything架構

Shared Nothing流派

特點：

1. 無限的彈性水平擴展
2. 強SQL支持（幾乎不需要妥協，無需指定分片策略，系統自動擴展）
3. 和單機數據庫一樣的事務支持
4. 跨數據中心故障自恢復級別的高可用能力

代表作品：

1. Google Spanner
2. TiDB 3.0及之前版本
3. CockroachDB

優點：

1. 無限水平擴展，沒有容量上限，對海量數據場景友好
2. 對金融級別的一致性ACID事務支持，業務改動代價小
3. 故障自恢復的高可用能力，運維省事
4. SQL能力強，和單機數據庫的體驗一直
   1. 例如：TiDB支持MySQL的絕大多少語法和網絡協議（覆蓋度92%）
5. 無限擴展的吞吐能力（和業務負載有關）

缺點：

1. 並非100%兼容傳統數據庫的語法
2. 對於一些極端場景（秒殺），延時不如單機數據庫（跨機，跨地域的分布式事務必然帶來更高延遲）
3. 例子：小事務平均latency：2ms（單機） Vs 5ms（分布式）

Shared Everything流派

代表作品：AWS Aurora、阿里雲PolarDB

Cloud-Native

• 通常由公有雲提供

存儲計算分離

• 無狀態SQL計算節點
• 計算節點通常直接復用MySQL,但是不存儲數據
• 遠程存儲（數據文件層）

Aurora可理解單機型數據庫，數據存儲時沒有分片，最大容量由單台服務器決定，存儲上限64T（一台服務器最大可插的硬盤），數據被全量拷貝到多台服務器上。

之前做法：binlog的主從復制

AWS做法：復制redo log而不是binlog，更少的IO路徑，更小的網絡包

優點：

1. 易用，100%兼容MySQL，業務兼容性好
2. 對一致性要求不高的場景，讀可以水平擴展（但是有上限）

缺點：

1. 本質上還是單機數據庫，如果要支持大數據量，仍然需要分庫分表
2. 內存和容量不匹配，在單表數據量大后，性能抖動嚴重
3. 跨機的事務一致性問題
4. 分析能力受限於單點，幾乎沒有分布式OLAP能力

下一代系統：分布式HTAP數據庫

HTAP的定義：Hybrid transactional/analytical processing,混合事務分析處理

• 分布式HTAP的標准：
• 業務透明的無限水平擴展能力
• 分布式事務的支持
• 多數據中心故障自恢復的高可用能力
• 提供高性能的分析能力
  • 提供列式存儲能力
• 在混合負載下，實時OLAP分析不影響OLAP事務
• 目前業界僅有TiDB 4.0能達到上述的要求
  • 　　TiDB + TiFlash（TiDB的列存擴展）

1. 分布式HTAP數據庫：TiDB + TiFlash

2. 為什么能實現OLAP和OLTP的徹底隔離，互不影響？
   1. 存儲和計算徹底分離
   2. 列式存儲(適用於OLAP)以副本擴展的形式存在
   3. 通過Multi raft架構進行日志級別的復制同步，業務層完全無感知
3. 擴展性依托TiDB的分布式架構，能做到水平擴展
   1. 數據同步不會成為瓶頸
      1. 面向實時分析設計，不需要額外的技術棧從數據庫同步到實時數倉

未來的數據庫的趨勢？

• 功能上以HTAP為基礎
• 面向雲特性設計
• 智能化
• 平台化

為什么是 HTAP？

在互聯網浪潮出現之前，企業的數據量普遍不大，特別是核心的業務數據，通常一個單機的數據庫就可以保存。那時候的存儲並不需要復雜的架構，所有的線上請求 (OLTP, Online Transactional Processing) 和后台分析 (OLAP, Online Analytical Processing) 都跑在同一個數據庫實例上。

隨着互聯網的發展，企業的業務數據量不斷增多，單機數據庫的容量限制制約了其在海量數據場景下的使用。因此在實際應用中，為了面對各種需求，OLTP、OLAP 在技術上分道揚鑣，在很多企業架構中，這兩類任務處理由不同團隊完成。當物聯網大數據應用不斷深入，具有海量的傳感器數據要求實時更新和查詢，對數據庫的性能要求也越來越高，此時，新的問題隨之出現：

1. OLAP 和 OLTP 系統間通常會有幾分鍾甚至幾小時的時延，OLAP 數據庫和 OLTP 數據庫之間的一致性無法保證，難以滿足對分析的實時性要求很高的業務場景。
   
2. 企業需要維護不同的數據庫以便支持兩類不同的任務，管理和維護成本高。

因此，能夠統一支持事務處理和工作負載分析的數據庫成為眾多企業的需求。在此背景下，由 Gartner 提出的 HTAP（混合事務 / 分析處理，Hybrid Transactional/Analytical Processing）成為希望。基於創新的計算存儲框架，HTAP 數據庫能夠在一份數據上同時支撐業務系統運行和 OLAP 場景，避免在傳統架構中，在線與離線數據庫之間大量的數據交互。此外，HTAP 基於分布式架構，支持彈性擴容，可按需擴展吞吐或存儲，輕松應對高並發、海量數據場景。

目前，實現 HTAP 的數據庫不多，主要有 PingCAP 的 TiDB、阿里雲的 HybridDB for MySQL、百度的 BaikalDB 等。其中，TiDB 是國內首家開源的 HTAP 分布式數據庫，接下來，本文將以此例進行深入分析。

TiDB典型應用場景

• 海量數據高並發OLTP系統
  • 不再分庫分表，不再使用妥協的數據庫中間件，業務不再受限制於基礎架構
• 海量數據高性能實時分析
  • 兼容MySQL,大數據量下比MySQL快1~2個數量級的融合OLTP和OLAP的HTAP數據庫
• 多源高吞吐匯總與實時計算
  • 多源（數十至數百異構數據源）高吞吐（數十萬QPS）匯聚寫入AD-Hoc准實時查詢
• 實時數倉
  • 通過TiSpark無縫連接Spark，無需ETL，提供實時的大規模復雜OLAP分析查詢能力。
• 金融級別多數據中心多活
  • 故障自動恢復，無需人工介入的真正意義上的高可用
• 雲數據庫
  • 同kubernetes、Docker等容器技術完美整合，自動調度有狀態的服務

OLTP場景

場景特點：

• 高頻SQL
• 數據量中等
• 相應延時低
• 讀多寫少

關注點：

• 高可用
• 故障自動修復
• 在線變更schema
• 多點寫入

金融OLTP場景

場景特點：

• 數據一致性
• 事務一致性
• 業務連續性

關注點：

• 傳統OLTP所有點
• 強一致性
• 高並發、高性能
• 故障容錯性
• 跨地域多活、容災故障自動修復

OLTP場景的TiDB方案

• TiDB場景優勢
  • 　　數據一致性保證
  • 　　在線DDL
  • 　　支持多點寫入
  • 　　自動故障檢測、選主、轉移
  • 　　計算存儲分離，快速擴容讀優點
• TiDB場景劣勢
  • 　　網絡交互多，導致延時增大
  • 　　有機器硬件要求（萬兆網+SSD）

HTAP場景TiDB

TiDB的TP起步階段

中台業務場景

業務需求：

• 微服務下的數據孤島問題
• 分片多維度查詢問題
• 需要靜態數據Join動態數據
• 需要完整SQL語義、支持復雜SQL
• 需要便於增量更新、索引維護
• 需要便於從binlog實時同步

TiDB非常適合中台場景

• 協議兼容，輕松同步MySQL
• 透明無障礙的跨分片查詢
• 數據實時落地
• 海量存儲允許多數據源匯聚
• 備庫-中台分析二合一

TiDB工作方式：

1、朴素工作方式（無Coprocessor）場景

 

2、Coprocessor場景

例如：聚合count、top、limit等都可以將計算任務從計算層下推TiKV（存儲層），經過2次計算。

 

TiDB集群HTAP能力的短板

• TiDB之間無法直接交換數據,匯總計算只能在當前會話的機器單台上進行（與MPP的架構區別）
• TiKV之間也無法在計算過程中交換數據
• 海量存儲（TiKV），半單機計算（TiDB）
  • 只能通過TiDB服務器Scale-Up改善
• Coprocessor無法處理需要數據交換的算子
  • join

分布式計算架構-TiSpark

• 借助TiSpark
  • 　　Spark是成熟的計算平台
  • 　　繼承Apache Spark生態
  • 　　向下銜接大數據生態圈

 

TiSpark能力差距

• 行存對於分析場景不友好
  • 數據的獲取效率、數據壓縮存放等場景
• 無法做到Workload隔離
  • 　　TiSpark對於TiKV的CPU和IO資源的占用

雙格式數據

行存 列存

TiFlash

新鮮數據的實時分析反哺業務

 

 

 TiDB容災部署實戰

1. 支持廣域網鏈接
   • 兩地三中心五副本方式部署
   • 同城兩中心提供讀寫服務
2. 支持單中心失效
   • 切換和恢復無需人員介入操作
3. 節點擴展和性能
   • 存儲節點按副本數量擴展
   • 支持性能的水平擴展

 

TiDB組件容災