碼上快樂

相關內容    簡體    繁體

小試國產開源HTAP分布式NewSQL數據庫TiDB-v5.3.0

本文轉載自   查看原文   2021-12-30 09:17   1075    經驗分享/ 數據庫/ 分布式

概述

定義

TiDB官網 https://pingcap.com/zh/ 最新版本為5.3.0

TiDB GitHub源碼 https://github.com/pingcap/tidb

TiDB是由國內PingCAP公司自主設計、研發的開源分布式關系型數據庫，是一款同時支持在線事務處理與在線分析處理 (Hybrid Transactional and Analytical Processing, HTAP，混合事務和分析處理，在同一個數據庫系統同時支持OLTP和OLAP） 的融合型分布式數據庫產品，具備水平擴容或者縮容、金融級高可用、實時 HTAP、雲原生的分布式數據庫、兼容 MySQL 5.7 協議和 MySQL 生態等重要特性，遷移便捷，運維成本極低。

目前國產分布式數據庫排名前三數據庫有TiDB、OceanBase、PolarDB-X；OceanBase為螞蟻集團完全自主研發，誕生較久早在2010年就開始建設；PolarDB-X則為阿里巴巴自主研發的雲原生分布式數據庫。TiDB是采用Go語言編寫，越來越多開源項目選擇Go，TiDB目標是為用戶提供一站式 OLTP (Online Transactional Processing-在線事務處理)、OLAP (Online Analytical Processing-在線數據分析)、HTAP 解決方案。TiDB官方提供社區版（開源）和企業版（付費）。

與傳統單機數據庫對比優勢

  • 純分布式架構，擁有良好的擴展性，支持彈性的擴縮容。
  • 支持 SQL，對外暴露 MySQL 的網絡協議，並兼容大多數 MySQL 的語法，在大多數場景下可以直接替換 MySQL。
  • 默認支持高可用，在少數副本失效的情況下，數據庫本身能夠自動進行數據修復和故障轉移，對業務透明。
  • 支持 ACID 事務，對於一些有強一致需求的場景友好，例如：銀行轉賬。
  • 具有豐富的工具鏈生態，覆蓋數據遷移、同步、備份等多種場景。

官方工具

  • 安裝部署
    • TiUP
    • TiDB Operator
  • 數據流轉
    • 數據遷入 - TiDB Data Migration
    • 增量數據遷出 - TiCDC
    • 數據導入 - TiDB Lightning
    • 數據導出 - Dumpling
  • 集群容災
    • Backup & Restore
  • 運維和可視化
    • TiDB Dashboard

核心特性

  • 一鍵水平擴容或者縮容：得益於 TiDB 存儲計算分離的架構的設計，可按需對計算、存儲分別進行在線擴容或者縮容，擴容或者縮容過程中對應用運維人員透明。
  • 金融級高可用：數據采用多副本存儲，數據副本通過 Multi-Raft 協議同步事務日志，多數派寫入成功事務才能提交，確保數據強一致性且少數副本發生故障時不影響數據的可用性。可按需配置副本地理位置、副本數量等策略滿足不同容災級別的要求。
  • 實時 HTAP：提供行存儲引擎 TiKV、列存儲引擎 TiFlash 兩款存儲引擎，TiFlash 通過 Multi-Raft Learner 協議實時從 TiKV 復制數據，確保行存儲引擎 TiKV 和列存儲引擎 TiFlash 之間的數據強一致。TiKV、TiFlash 可按需部署在不同的機器，解決 HTAP 資源隔離的問題。
  • 雲原生的分布式數據庫：專為雲而設計的分布式數據庫，通過 TiDB Operator 可在公有雲、私有雲、混合雲中實現部署工具化、自動化。
  • 兼容 MySQL 5.7 協議和 MySQL 生態：兼容 MySQL 5.7 協議、MySQL 常用的功能、MySQL 生態，應用無需或者修改少量代碼即可從 MySQL 遷移到 TiDB。提供豐富的數據遷移工具幫助應用便捷完成數據遷移。

產品特點

  • 融合的數據平台：打破數據壁壘，合而為一。事務性與分析型處理完全基於一體化的數據基座。
  • 實時的商業分析：在線數據分析與決策，分秒必爭。強一致性保障基於數據的決策，分毫不差。
  • 敏捷的業務創新：數據庫，亦服務；雲原生，高彈性；金融級高可用。
  • 開放的生態系統：基於 CNCF 項目的中國領先開源社區。無縫支持多雲架構對接豐富的數據工具生態。

應用場景

  • 對數據一致性及高可靠、系統高可用、可擴展性、容災要求較高的金融行業屬性的場景。
  • 對存儲容量、可擴展性、並發要求較高的海量數據及高並發的 OLTP 場景。
  • Real-time HTAP 場景。
  • 數據匯聚、二次加工處理的場景。

部署

部署規划

單台 Linux 服務器， TiDB最小規模的 TiDB 集群拓撲，模擬生產環境下的部署步驟。

實例 個數 IP 配置
TiKV 3 192.168.50.95、192.168.50.95、192.168.50.95 避免端口和目錄沖突
TiDB 1 192.168.50.95 默認端口 全局目錄配置
PD 1 192.168.50.95 默認端口 全局目錄配置
TiFlash 1 192.168.50.95 默認端口 全局目錄配置
Monitor 1 192.168.50.95 默認端口 全局目錄配置

單機部署集群

# 下載並安裝 TiUP
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
# 聲明全局環境變量，本人使用的是root安裝
source /root/.bash_profile
# 安裝 TiUP 的 cluster 組件
tiup cluster
# 由於模擬多機部署，需要通過 root 用戶調大 sshd 服務的連接數限制，修改 /etc/ssh/sshd_config 將 MaxSessions 調至 20。重啟 sshd 服務
service sshd restart
# 創建啟動集群的yaml配置文件,內容如下
vi topo.yaml

global:
 user: "tidb"
 ssh_port: 22
 deploy_dir: "/tidb-deploy"
 data_dir: "/tidb-data"

# # Monitored variables are applied to all the machines.
monitored:
 node_exporter_port: 9100
 blackbox_exporter_port: 9115

server_configs:
 tidb:
   log.slow-threshold: 300
 tikv:
   readpool.storage.use-unified-pool: false
   readpool.coprocessor.use-unified-pool: true
 pd:
   replication.enable-placement-rules: true
   replication.location-labels: ["host"]
 tiflash:
   logger.level: "info"

pd_servers:
 - host: 192.168.50.95

tidb_servers:
 - host: 192.168.50.95

tikv_servers:
 - host: 192.168.50.95
   port: 20160
   status_port: 20180
   config:
     server.labels: { host: "tikv-host-1" }

 - host: 192.168.50.95
   port: 20161
   status_port: 20181
   config:
     server.labels: { host: "tikv-host-2" }

 - host: 192.168.50.95
   port: 20162
   status_port: 20182
   config:
     server.labels: { host: "tikv-host-3" }

tiflash_servers:
 - host: 192.168.50.95

monitoring_servers:
 - host: 192.168.50.95

grafana_servers:
 - host: 192.168.50.95

保存內容后下面進行正式部署和啟動

# 執行集群部署命令，集群的名稱和我們配置文件一致tidb-cluster，集群版本可以通過 tiup list tidb 命令來查看當前支持部署的 TiDB 版本
tiup cluster deploy tidb-cluster v5.3.0 ./topo.yaml --user root -p
# 執行上面的命令出現下面的提示后按照引導，輸入”y”及 root 密碼，來完成部署

image-20211225180219626

# 啟動集群：
tiup cluster start tidb-cluster
#查看當前已經部署的集群列表
tiup cluster list
# 查看集群的拓撲結構和狀態
tiup cluster display tidb-cluster

image-20211225182548773

# 由於我本機已安裝mysql，所以可以直接運行mysql客戶端,訪問 TiDB 數據庫，密碼為空
mysql -h 192.168.50.95 -P 4000 -u root

image-20211225181723827

訪問TiDB的Grafana監控監控頁面，默認用戶名和密碼均為admin, http://192.168.50.95:3000
訪問TiDB集群Dashboard監控頁面, 默認用戶名為root，密碼為空,http://192.168.50.95:2379/dashboard

image-20211225184951040

體驗HTAP

基本概念

  • HTAP 存儲引擎：行存 (Row-store) 與列存 (columnar-store) 同時存在，自動同步，保持強一致性。行存為在線事務處理 OLTP 提供優化，列存則為在線分析處理 OLAP 提供性能優化。
  • HTAP 數據一致性：作為一個分布式事務型的鍵值數據庫，TiKV 提供了滿足 ACID 約束的分布式事務接口，並通過Raft協議保證了多副本數據一致性以及高可用。TiFlash 通過 Multi-Raft Learner 協議實時從 TiKV 復制數據，確保與 TiKV 之間的數據強一致。
  • HTAP 數據隔離性：TiKV、TiFlash 可按需部署在不同的機器，解決 HTAP 資源隔離的問題。
  • MPP 計算引擎：從 v5.0 版本起，TiFlash 引入了分布式計算框架MPP，允許節點之間的數據交換並提供高性能、高吞吐的 SQL 算法，可以大幅度縮短分析查詢的執行時間。

體驗

# 啟動 TiDB 集群
tiup playground
# 使用以下命令安裝數據生成工具
tiup install bench
# 使用以下命令生成數據，當命令行輸出Finished時，表示數據生成完畢。
tiup bench tpch --sf=1 prepare

適用場景

TiDB HATP 可以滿足企業海量數據的增產需求、降低運維的風險成本、與現有的大數據棧無縫結合，從而實現數據資產價值的實時變現，以下是三種 HTAP 典型適用場景：

  • 混合負載場景：當將 TiDB 應用於在線實時分析處理的混合負載場景時，開發人員只需要提供一個入口，TiDB 將自動根據業務類型選擇不同的處理引擎。
  • 實時流處理場景：當將 TiDB 應用於實時流處理場景時，TiDB 能保證源源不斷流入系統的數據實時可查，同時可兼顧高並發數據服務與 BI 查詢。
  • 數據中樞場景：當將 TiDB 應用於數據中樞場景時，TiDB 作為數據中樞可以無縫連接數據業務層和數據倉庫層，滿足不同業務的需求。

架構

總體架構

image-20211225195741729

  • 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 內部，數據是以列式的形式進行存儲，主要的功能是為分析型的場景加速。
  • TiSpark 作為 TiDB 中解決用戶復雜 OLAP 需求的主要組件，將 Spark SQL 直接運行在 TiDB 存儲層上，同時融合 TiKV 分布式集群的優勢，並融入大數據社區生態。至此，TiDB 可以通過一套系統，同時支持 OLTP 與 OLAP，免除用戶數據同步的煩惱。

image-20211225200755421

  • TiKV 的選擇是 Key-Value 模型，並且提供有序遍歷方法

    • 巨大的 Map，也就是存儲的是 Key-Value Pairs（鍵值對）。
    • Map 中的 Key-Value pair 按照 Key 的二進制順序有序，也就是可以 Seek 到某一個 Key 的位置，然后不斷地調用 Next 方法以遞增的順序獲取比這個 Key 大的 Key-Value。

  • 本地存儲

    • TiKV把數據保存在 RocksDB 中，具體的數據落地由 RocksDB 負責， RocksDB 是由 Facebook 開源的一個非常優秀的單機 KV 存儲引擎，可以滿足 TiKV 對單機引擎的各種要求。這里可以簡單的認為 RocksDB 是一個單機的持久化 Key-Value Map。

  • Raft協議

    • 通過單機的 RocksDB，TiKV 可以將數據快速地存儲在磁盤上；通過 Raft，將數據復制到多台機器上，以防單機失效。數據的寫入是通過 Raft 這一層的接口寫入，而不是直接寫 RocksDB。通過實現 Raft，TiKV 變成了一個分布式的 Key-Value 存儲，少數幾台機器宕機也能通過原生的 Raft 協議自動把副本補全，可以做到對業務無感知。

      image-20211225201138946

  • Region

    • 按照 Key 分 Range，某一段連續的 Key 都保存在一個存儲節點上，將整個 Key-Value 空間分成很多段，每一段是一系列連續的 Key，將每一段叫做一個 Region，並且會盡量保持每個 Region 中保存的數據不超過一定的大小，目前在 TiKV 中默認是 96MB。每一個 Region 都可以用 [StartKey，EndKey) 這樣一個左閉右開區間來描述。
      • 以 Region 為單位，將數據分散在集群中所有的節點上，並且盡量保證每個節點上服務的 Region 數量差不多。
      • 以 Region 為單位做 Raft 的復制和成員管理。
    • 以 Region 為單位做數據的分散和復制，TiKV 就成為了一個分布式的具備一定容災能力的 KeyValue 系統，不用再擔心數據存不下，或者是磁盤故障丟失數據的問題。

    image-20211225212616844

  • MVCC：TiKV 的 MVCC 實現是通過在 Key 后面添加版本號來實現。

  • 分布式事務：TiKV 的事務采用的是 Google 在 BigTable 中使用的事務模型。

計算

  • 表數據與 Key-Value 的映射關系

  • 索引數據和 Key-Value 的映射關系

  • 元數據管理

    • TiDB 中每個 Database 和 Table 都有元信息，也就是其定義以及各項屬性。這些信息也需要持久化，TiDB 將這些信息也存儲在了 TiKV 中。

  • SQL層

    • TiDB 的 SQL 層，即 TiDB Server，負責將 SQL 翻譯成 Key-Value 操作，將其轉發給共用的分布式 Key-Value 存儲層 TiKV，然后組裝 TiKV 返回的結果，最終將查詢結果返回給客戶端。

    • SQL計算

      image-20211225213054327

    • 計算應該需要盡量靠近存儲節點，以避免大量的 RPC 調用。首先，SQL 中的謂詞條件 name = "TiDB" 應被下推到存儲節點進行計算，這樣只需要返回有效的行，避免無意義的網絡傳輸。然后，聚合函數 Count(*) 也可以被下推到存儲節點，進行預聚合，每個節點只需要返回一個 Count(*) 的結果即可，再由 SQL 層將各個節點返回的 Count(*) 的結果累加求和。

image-20211225213130534

  • SQL 層架構

    • 用戶的 SQL 請求會直接或者通過 Load Balancer 發送到 TiDB Server，TiDB Server 會解析 MySQL Protocol Packet，獲取請求內容，對 SQL 進行語法解析和語義分析，制定和優化查詢計划，執行查詢計划並獲取和處理數據。數據全部存儲在 TiKV 集群中，所以在這個過程中 TiDB Server 需要和 TiKV 交互，獲取數據。最后 TiDB Server 需要將查詢結果返回給用戶。

    image-20211225213556621

調度

PD (Placement Driver) 是 TiDB 集群的管理模塊，同時也負責集群數據的實時調度。本文檔介紹一下 PD 的設計思想和關鍵概念。

第一類：作為一個分布式高可用存儲系統，必須滿足的需求，包括幾種

  • 副本數量不能多也不能少
  • 副本需要根據拓撲結構分布在不同屬性的機器上
  • 節點宕機或異常能夠自動合理快速地進行容災

第二類：作為一個良好的分布式系統，需要考慮的地方包括

  • 維持整個集群的 Leader 分布均勻
  • 維持每個節點的儲存容量均勻
  • 維持訪問熱點分布均勻
  • 控制負載均衡的速度，避免影響在線服務
  • 管理節點狀態，包括手動上線/下線節點

滿足上面需求首先需要收集足夠的信息，比如每個節點的狀態、每個 Raft Group 的信息、業務訪問操作的統計等；其次需要設置一些策略，PD 根據這些信息以及調度的策略，制定出盡量滿足前面所述需求的調度計划；最后需要一些基本的操作，來完成調度計划。

調度依賴於整個集群信息的收集，簡單來說，調度需要知道每個 TiKV 節點的狀態以及每個 Region 的狀態。TiKV 集群會向 PD 匯報兩類消息，TiKV 節點信息和 Region 信息。

  • 調度策略
    • 一個 Region 的副本數量正確
    • 一個 Raft Group 中的多個副本不在同一個位置
    • 副本在 Store 之間的分布均勻分配
    • Leader 數量在 Store 之間均勻分配
    • 訪問熱點數量在 Store 之間均勻分配
    • 各個 Store 的存儲空間占用大致相等
    • 控制調度速度，避免影響在線服務
  • 調度的實現
    • PD 不斷地通過 Store 或者 Leader 的心跳包收集整個集群信息，並且根據這些信息以及調度策略生成調度操作序列。每次收到 Region Leader 發來的心跳包時，PD 都會檢查這個 Region 是否有待進行的操作，然后通過心跳包的回復消息，將需要進行的操作返回給 Region Leader，並在后面的心跳包中監測執行結果。

存儲引擎

TiKV

TiKV 是一個分布式事務型的鍵值數據庫，提供了滿足 ACID 約束的分布式事務接口，並且通過Raft協議保證了多副本數據一致性以及高可用。TiKV 作為 TiDB 的存儲層，為用戶寫入 TiDB 的數據提供了持久化以及讀寫服務，同時還存儲了 TiDB 的統計信息數據。

  • Region 與 RocksDB：雖然 TiKV 將數據按照范圍切割成了多個 Region，但是同一個節點的所有 Region 數據仍然是不加區分地存儲於同一個 RocksDB 實例上，而用於 Raft 協議復制所需要的日志則存儲於另一個 RocksDB 實例。這樣設計的原因是因為隨機 I/O 的性能遠低於順序 I/O，所以 TiKV 使用同一個 RocksDB 實例來存儲這些數據，以便不同 Region 的寫入可以合並在一次 I/O 中。
  • Region 與 Raft 協議：Region 與副本之間通過 Raft 協議來維持數據一致性，任何寫請求都只能在 Leader 上寫入，並且需要寫入多數副本后（默認配置為 3 副本，即所有請求必須至少寫入兩個副本成功）才會返回客戶端寫入成功。
  • RocksDB是由 Facebook 基於 LevelDB 開發的一款提供鍵值存儲與讀寫功能的 LSM-tree 架構引擎。用戶寫入的鍵值對會先寫入磁盤上的 WAL (Write Ahead Log)，然后再寫入內存中的跳表（SkipList，這部分結構又被稱作 MemTable）。LSM-tree 引擎由於將用戶的隨機修改（插入）轉化為了對 WAL 文件的順序寫，因此具有比 B 樹類存儲引擎更高的寫吞吐。內存中的數據達到一定閾值后，會刷到磁盤上生成 SST 文件 (Sorted String Table)，SST 又分為多層（默認至多 6 層），每一層的數據達到一定閾值后會挑選一部分 SST 合並到下一層，每一層的數據是上一層的 10 倍（因此 90% 的數據存儲在最后一層）。RocksDB 允許用戶創建多個 ColumnFamily ，這些 ColumnFamily 各自擁有獨立的內存跳表以及 SST 文件，但是共享同一個 WAL 文件，這樣的好處是可以根據應用特點為不同的 ColumnFamily 選擇不同的配置，但是又沒有增加對 WAL 的寫次數。

TiFlash

TiFlash 是 TiDB HTAP 形態的關鍵組件，它是 TiKV 的列存擴展，在提供了良好的隔離性的同時，也兼顧了強一致性。列存副本通過 Raft Learner 協議異步復制，但是在讀取的時候通過 Raft 校對索引配合 MVCC 的方式獲得 Snapshot Isolation 的一致性隔離級別。這個架構很好地解決了 HTAP 場景的隔離性以及列存同步的問題。

image-20211229214022873

上圖為 TiDB HTAP 形態架構，其中包含 TiFlash 節點。

TiFlash 提供列式存儲，且擁有借助 ClickHouse 高效實現的協處理器層。除此以外，它與 TiKV 非常類似，依賴同樣的 Multi-Raft 體系，以 Region 為單位進行數據復制和分散。

TiFlash 主要有異步復制、一致性、智能選擇、計算加速等幾個核心特性。

  • 異步復制：TiFlash 中的副本以特殊角色 (Raft Learner) 進行異步的數據復制。這表示當 TiFlash 節點宕機或者網絡高延遲等狀況發生時，TiKV 的業務仍然能確保正常進行。這套復制機制也繼承了 TiKV 體系的自動負載均衡和高可用：並不用依賴附加的復制管道，而是直接以多對多方式接收 TiKV 的數據傳輸；且只要 TiKV 中數據不丟失，就可以隨時恢復 TiFlash 的副本。
  • 一致性：TiFlash 提供與 TiKV 一樣的快照隔離支持，且保證讀取數據最新（確保之前寫入的數據能被讀取）。這個一致性是通過對數據進行復制進度校驗做到的。每次收到讀取請求，TiFlash 中的 Region 副本會向 Leader 副本發起進度校對（一個非常輕的 RPC 請求），只有當進度確保至少所包含讀取請求時間戳所覆蓋的數據之后才響應讀取。
  • 智能選擇：TiDB 可以自動選擇使用 TiFlash 列存或者 TiKV 行存，甚至在同一查詢內混合使用提供最佳查詢速度。這個選擇機制與 TiDB 選取不同索引提供查詢類似：根據統計信息判斷讀取代價並作出合理選擇。
  • 計算加速：TiFlash 對 TiDB 的計算加速分為兩部分：列存本身的讀取效率提升以及為 TiDB 分擔計算。其中分擔計算的原理和 TiKV 的協處理器一致：TiDB 會將可以由存儲層分擔的計算下推。能否下推取決於 TiFlash 是否可以支持相關下推

**本人博客網站 **IT小神 www.itxiaoshen.com


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 國產開源數據庫：騰訊雲TBase在分布式HTAP領域的探索與實踐 TiDB 簡介（國產分布式數據庫） 最火的分布式 HTAP 數據庫 TiDB - 入門實踐教程 TiDB 開源分布式關系型數據庫 敢啃“硬骨頭”，開源分布式數據庫TiDB如何煉成？ (二)分布式數據庫tidb-事務 (一)分布式數據庫tidb-簡介 分布式數據庫TiDB的部署 (二)分布式數據庫tidb-事務 從NoSQL到NewSQL，談交易型分布式數據庫建設要點
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM