分庫分表:TIDB,你是來搶生意的?不講碼德?


     大家好,我是老梁。下面這篇文章來自於我的好朋友狼王的公衆號 「Garnett的Java之路」。



隨着互聯網的發展,業務越來越龐大,客戶羣體也越來越多,所要存儲的數據也越來越多,慢慢的就出現了分庫分表的中間件。

比如cobar,TDDL,atlas,sharding-jdbc,mycat等,都是非常優秀的產品,解決了各種問題,但是引入了中間件肯定就會增加各方面的維護成本等

這篇帶大家瞭解一款替代分庫分表的解決方案:分佈式數據庫:TIDB

前言

如今硬件的性價比越來越高,網絡傳輸速度越來越快,數據庫分層的趨勢逐漸顯現,人們已經不再強求用一個解決方案來解決所有的存儲問題,而是通過分層,讓緩存與數據庫負責各自擅長的業務場景。


當前數據庫領域面臨各種問題,如在縮放、一致性、大數據分析、與雲基礎架構集成等方面均存在諸多問題,現有的數據庫解決方案和大數據分析引擎解決方案基本處於割裂的狀態,由於 Oracle、MySQL 數據庫並不是面向分佈式環境而設計,因此即使勉強通過分庫、分表或中間件的方式,在數據庫層面做了分片,從本質上看也只是複製了相同的堆棧,而非針對分佈式系統進行存儲和計算優化,這正是進行跨業務查詢或跨物理機查詢和寫入十分繁瑣的本質原因。NoSQL 雖然解決了數據庫彈性擴展的難題,但是卻放棄了數據的強一致性以及對 ACID 事務的支持,帶來了新的問題。


爲了解決這一問題,TiDB 在架構上將計算和存儲層進行高度的抽象和分離,對混合負載的場景通過 IO 優先級隊列,智能副本調度,行列混合存儲等技術使其變爲可能。

大家可能都沒有聽過TIDB這款分佈式數據庫,但是它已經出現很久了,隨着不斷完善,也受到越來越多的企業喜愛,接下來讓我們開始瞭解TIDB吧!

TIDB簡介

TIDB是什麼?

TiDB 是一個分佈式 NewSQL 數據庫。它支持水平彈性擴展、ACID 事務、標準 SQL、MySQL 語法和 MySQL 協議,具有數據強一致的高可用特性,是一個不僅適合 OLTP 場景還適合OLAP 場景的混合數據庫。

TIDB怎麼來的?

開源分佈式緩存服務 Codis 的作者,PingCAP 聯合創始人& CTO ,資深 infrastructure 工程師的黃東旭,擅長分佈式存儲系統的設計與實現,開源狂熱分子的技術大神級別人物。即使在互聯網如此繁榮的今天,在數據庫這片邊界模糊且不確定地帶,他還在努力尋找確定性的實踐方向。

2012 年底,他看到 Google 發佈的兩篇論文,得到了很大的觸動,這兩篇論文描述了 Google 內部使用的一個海量關係型數據庫 F1/Spanner ,解決了關係型數據庫、彈性擴展以及全球分佈的問題,並在生產中大規模使用。“如果這個能實現,對數據存儲領域來說將是顛覆性的”,黃東旭爲完美方案的出現而興奮, PingCAP TiDB 在此基礎上誕生了。

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 那樣依賴底層的分佈式文件系統,在性能和靈活性上能更好,這個對於在線業務來說是非常重要。


所以一套這樣的架構是由這樣的3類角色共同組建而成。每個部分的解釋如下:


1.TiDB Server

TiDB Server 負責接收 SQL 請求,處理 SQL 相關的邏輯,並通過 PD 找到存儲計算所需數據的 TiKV 地址,與 TiKV 交互獲取數據,最終返回結果。TiDB Server 是無狀態的,其本身並不存儲數據,只負責計算,可以無限水平擴展,可以通過負載均衡組件(如LVS、HAProxy 或 F5)對外提供統一的接入地址。

2.PD Server

Placement Driver (簡稱 PD) 是整個集羣的管理模塊,其主要工作有三個:一是存儲集羣的元信息(某個 Key 存儲在哪個 TiKV 節點);二是對 TiKV 集羣進行調度和負載均衡(如數據的遷移、Raft group leader 的遷移等);三是分配全局唯一且遞增的事務 ID。PD 是一個集羣,需要部署奇數個節點,一般線上推薦至少部署 3 個節點。

3.TiKV Server

TiKV Server 負責存儲數據,從外部看 TiKV 是一個分佈式的提供事務的 Key-Value 存儲引擎。存儲數據的基本單位是 Region,每個 Region 負責存儲一個 Key Range (從 StartKey 到 EndKey 的左閉右開區間)的數據,每個 TiKV 節點會負責多個 Region 。TiKV 使用 Raft 協議做複製,保持數據的一致性和容災。副本以 Region 爲單位進行管理,不同節點上的多個 Region 構成一個 Raft Group,互爲副本。數據在多個 TiKV 之間的負載均衡由 PD 調度,這裏也是以 Region 爲單位進行調度。

TIDB五大核心特性

一鍵水平擴縮容

得益於 TiDB 存儲計算分離的架構的設計,可按需對計算、存儲分別進行在線擴容或者縮容,擴容或者縮容過程中對應用運維人員透明。

金融級高可用

數據採用多副本存儲,數據副本通過 Multi-Raft 協議同步事務日誌,多數派寫入成功事務才能提交,確保數據強一致性且少數副本發生故障時不影響數據的可用性。可按需配置副本地理位置、副本數量等策略滿足不同容災級別的要求。

實時HTAP

提供行存儲引擎 TiKV、列存儲引擎 TiFlash 兩款存儲引擎,TiFlash 通過 Multi-Raft Learner 協議實時從 TiKV 複製數據,確保行存儲引擎 TiKV 和列存儲引擎 TiFlash 之間的數據強一致。TiKV、TiFlash 可按需部署在不同的機器,解決 HTAP 資源隔離的問題。

雲原生的分佈式數據庫

專爲雲而設計的分佈式數據庫,通過 TiDB Operator 可在公有云、私有云、混合雲中實現部署工具化、自動化

兼容MYSQL5.7

專爲雲而設計的分佈式數據庫,通過 TiDB Operator 可在公有云、私有云、混合雲中實現部署工具化、自動化

TIDB四大核心應用場景

HTAP 給開發者提供了一個實時數據分析方面的新思路,不需要再去維護另一個離線的數據倉庫,既減輕了 ETL 的工作,又能節省很大一部分建立數據倉庫所用到的存儲和計算成本,HTAP 將是未來的重要趨勢。

黃東旭介紹了 TiDB 的四個主要應用場景,一是 MySQL 分片與合併;二是直接替換 MySQL;三是用做數據倉庫;四是作爲其他系統的一個模塊。

MySQL分片與合併

Syncer:


TiDB 應用的第一類場景是 MySQL 的分片與合併。對於已經在用 MySQL 的業務,分庫、分表、分片、中間件是常用手段,隨着分片的增多,跨分片查詢是一大難題。TiDB 在業務層兼容 MySQL 的訪問協議,PingCAP 做了一個數據同步的工具——Syncer,它可以把 TiDB 作爲一個 MySQL Slave,將 TiDB 作爲現有數據庫的從庫接在主 MySQL 庫的後方,在這一層將數據打通,可以直接進行復雜的跨庫、跨表、跨業務的實時 SQL 查詢。黃東旭提到,過去的數據庫都是一主多從,有了 TiDB 以後,可以反過來做到多主一從。

替換MySQL

第二類場景是用 TiDB 直接去替換 MySQL。如果你的IT架構在搭建之初並未考慮分庫分表的問題,全部用了 MySQL,隨着業務的快速增長,海量高併發的 OLTP 場景越來越多,如何解決架構上的弊端呢?

在一個 TiDB 的數據庫上,所有業務場景不需要做分庫分表,所有的分佈式工作都由數據庫層完成。TiDB 兼容 MySQL 協議,所以可以直接替換 MySQL,而且基本做到了開箱即用,完全不用擔心傳統分庫分表方案帶來繁重的工作負擔和複雜的維護成本,友好的用戶界面讓常規的技術人員可以高效地進行維護和管理。另外,TiDB 具有 NoSQL 類似的擴容能力,在數據量和訪問流量持續增長的情況下能夠通過水平擴容提高系統的業務支撐能力,並且響應延遲穩定。

黃東旭在演講中提到了摩拜單車的案例,摩拜早期的數據庫全部用 MySQL,隨着業務的快速增長,MySQL 的弊端逐漸顯現,摩拜單車於 2017 年初開始使用 TiDB 替換 MySQL。如今,摩拜的 IT 系統中已部署了數套 TiDB 集羣,近百個節點,承載着數十 TB 的各類數據。

數據倉庫

TiDB 本身是一個分佈式系統,第三種使用場景是將 TiDB 當作數據倉庫使用。TPC-H 是數據分析領域的一個測試集,TiDB 2.0 在 OLAP 場景下的性能有了大幅提升,原來只能在數據倉庫裏面跑的一些複雜的 Query,在 TiDB 2.0 裏面跑,時間基本都能控制在 10 秒以內。當然,因爲 OLAP 的範疇非常大,TiDB 的 SQL 也有搞不定的情況,爲此 PingCAP 開源了 TiSparkTiSpark 是一個 Spark 插件,用戶可以直接用 Spark SQL 實時地在 TiKV 上做大數據分析。

作爲其他系統的模塊

TiDB 是一個傳統的存儲跟計算分離的項目,其底層的 Key-Value 層,可以單獨作爲一個 HBase 的 Replacement 來用,它同時支持跨行事務。TiDB 對外提供兩個 API 接口,一個是 ACID Transaction 的 API,用於支持跨行事務;另一個是 Raw API,它可以做單行的事務,換來的是整個性能的提升,但不提供跨行事務的 ACID 支持。用戶可以根據自身的需求在兩個 API 之間自行選擇。例如有一些用戶直接在 TiKV 之上實現了 Redis 協議,將 TiKV 替換一些大容量,對延遲要求不高的 Redis 場景。

與MySQL兼容性對比

TiDB 支持包括跨行事務,JOIN 及子查詢在內的絕大多數 MySQL 的語法,用戶可以直接使用現有的 MySQL 客戶端連接。如果現有的業務已經基於 MySQL 開發,大多數情況不需要修改代碼即可直接替換單機的 MySQL。

包括現有的大多數 MySQL 運維工具(如 PHPMyAdmin, Navicat, MySQL Workbench 等),以及備份恢復工具(如 mysqldump, mydumper/myloader)等都可以直接使用。

不過一些特性由於在分佈式環境下沒法很好的實現,目前暫時不支持或者是表現與 MySQL 有差異。

一些 MySQL 語法在 TiDB 中可以解析通過,但是不會做任何後續的處理,例如 Create Table 語句中 Engine 以及 Partition 選項,都是解析並忽略。

不支持的特性有以下這些

存儲過程,視圖,觸發器,自定義函數,外鍵約束,全文索引,空間索引,非 UTF8 字符集等

總結

本文帶你瞭解了TIDB這款分佈式數據庫,它的特性,應用場景以及與MySQl的兼容性對比,下篇將會介紹TIDB的部署搭建,計算,存儲,調度方面的知識!

假如面試中你被問到這些,我相信你看了這篇一定能撥動面試官的心!


希望你們是我最好的觀衆!

樂於輸出乾貨的Java技術公衆號:Garnett的Java之路。公衆號內有大量的技術文章、海量視頻資源、精美腦圖,不妨來關注一下!回覆【資料】領取大量學習資源和免費書籍!


轉發朋友圈是對我最大的支持!
 覺得有點東西就點一下“贊和在看”吧!感謝大家的支持了!

本文分享自微信公衆號 - 瓜農老梁(gh_01130ae30a83)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章