分庫(kù)分表：TIDB，你是來(lái)?yè)屔獾?？不講碼德？

隨著互聯(lián)網(wǎng)的發(fā)展，業(yè)務(wù)越來(lái)越龐大，客戶群體也越來(lái)越多，所要存儲(chǔ)的數(shù)據(jù)也越來(lái)越多，慢慢的就出現(xiàn)了分庫(kù)分表的中間件。

比如cobar，TDDL，atlas，sharding-jdbc，mycat等，都是非常優(yōu)秀的產(chǎn)品，解決了各種問(wèn)題，但是引入了中間件肯定就會(huì)增加各方面的維護(hù)成本等

這篇帶大家了解一款替代分庫(kù)分表的解決方案：分布式數(shù)據(jù)庫(kù)：TIDB

 

前言

如今硬件的性價(jià)比越來(lái)越高，網(wǎng)絡(luò)傳輸速度越來(lái)越快，數(shù)據(jù)庫(kù)分層的趨勢(shì)逐漸顯現(xiàn)，人們已經(jīng)不再?gòu)?qiáng)求用一個(gè)解決方案來(lái)解決所有的存儲(chǔ)問(wèn)題，而是通過(guò)分層，讓緩存與數(shù)據(jù)庫(kù)負(fù)責(zé)各自擅長(zhǎng)的業(yè)務(wù)場(chǎng)景。

當(dāng)前數(shù)據(jù)庫(kù)領(lǐng)域面臨各種問(wèn)題，如在縮放、一致性、大數(shù)據(jù)分析、與云基礎(chǔ)架構(gòu)集成等方面均存在諸多問(wèn)題，現(xiàn)有的數(shù)據(jù)庫(kù)解決方案和大數(shù)據(jù)分析引擎解決方案基本處于割裂的狀態(tài)，由于 Oracle、MySQL 數(shù)據(jù)庫(kù)并不是面向分布式環(huán)境而設(shè)計(jì)，因此即使勉強(qiáng)通過(guò)分庫(kù)、分表或中間件的方式，在數(shù)據(jù)庫(kù)層面做了分片，從本質(zhì)上看也只是復(fù)制了相同的堆棧，而非針對(duì)分布式系統(tǒng)進(jìn)行存儲(chǔ)和計(jì)算優(yōu)化，這正是進(jìn)行跨業(yè)務(wù)查詢或跨物理機(jī)查詢和寫入十分繁瑣的本質(zhì)原因。NoSQL 雖然解決了數(shù)據(jù)庫(kù)彈性擴(kuò)展的難題，但是卻放棄了數(shù)據(jù)的強(qiáng)一致性以及對(duì) ACID 事務(wù)的支持，帶來(lái)了新的問(wèn)題。

為了解決這一問(wèn)題，TiDB 在架構(gòu)上將計(jì)算和存儲(chǔ)層進(jìn)行高度的抽象和分離，對(duì)混合負(fù)載的場(chǎng)景通過(guò) IO 優(yōu)先級(jí)隊(duì)列，智能副本調(diào)度，行列混合存儲(chǔ)等技術(shù)使其變?yōu)榭赡堋?/span>

大家可能都沒(méi)有聽過(guò)TIDB這款分布式數(shù)據(jù)庫(kù)，但是它已經(jīng)出現(xiàn)很久了，隨著不斷完善，也受到越來(lái)越多的企業(yè)喜愛，接下來(lái)讓我們開始了解TIDB吧！

 

TIDB簡(jiǎn)介

TIDB是什么？

TiDB 是一個(gè)分布式 NewSQL 數(shù)據(jù)庫(kù)。它支持水平彈性擴(kuò)展、ACID 事務(wù)、標(biāo)準(zhǔn) SQL、MySQL 語(yǔ)法和 MySQL 協(xié)議，具有數(shù)據(jù)強(qiáng)一致的高可用特性，是一個(gè)不僅適合 OLTP 場(chǎng)景還適合OLAP 場(chǎng)景的混合數(shù)據(jù)庫(kù)。

TIDB怎么來(lái)的？

開源分布式緩存服務(wù) Codis 的作者，PingCAP 聯(lián)合創(chuàng)始人& CTO ，資深 infrastructure 工程師的黃東旭，擅長(zhǎng)分布式存儲(chǔ)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)，開源狂熱分子的技術(shù)大神級(jí)別人物。即使在互聯(lián)網(wǎng)如此繁榮的今天，在數(shù)據(jù)庫(kù)這片邊界模糊且不確定地帶，他還在努力尋找確定性的實(shí)踐方向。

2012 年底，他看到 Google 發(fā)布的兩篇論文，得到了很大的觸動(dòng)，這兩篇論文描述了 Google 內(nèi)部使用的一個(gè)海量關(guān)系型數(shù)據(jù)庫(kù) F1/Spanner ，解決了關(guān)系型數(shù)據(jù)庫(kù)、彈性擴(kuò)展以及全球分布的問(wèn)題，并在生產(chǎn)中大規(guī)模使用。“如果這個(gè)能實(shí)現(xiàn)，對(duì)數(shù)據(jù)存儲(chǔ)領(lǐng)域來(lái)說(shuō)將是顛覆性的”，黃東旭為完美方案的出現(xiàn)而興奮， PingCAP 的 TiDB 在此基礎(chǔ)上誕生了。

 

TIDB的架構(gòu)

TiDB在整體架構(gòu)基本是參考 Google Spanner 和 F1 的設(shè)計(jì)，上分兩層為 TiDB 和 TiKV 。TiDB 對(duì)應(yīng)的是 Google F1， 是一層無(wú)狀態(tài)的 SQL Layer ，兼容絕大多數(shù) MySQL 語(yǔ)法，對(duì)外暴露 MySQL 網(wǎng)絡(luò)協(xié)議，負(fù)責(zé)解析用戶的 SQL 語(yǔ)句，生成分布式的 Query Plan，翻譯成底層 Key Value 操作發(fā)送給 TiKV ， TiKV 是真正的存儲(chǔ)數(shù)據(jù)的地方，對(duì)應(yīng)的是 Google Spanner ，是一個(gè)分布式 Key Value 數(shù)據(jù)庫(kù)，支持彈性水平擴(kuò)展，自動(dòng)的災(zāi)難恢復(fù)和故障轉(zhuǎn)移（高可用），以及 ACID 跨行事務(wù)。值得一提的是 TiKV 并不像 HBase 或者 BigTable 那樣依賴底層的分布式文件系統(tǒng)，在性能和靈活性上能更好，這個(gè)對(duì)于在線業(yè)務(wù)來(lái)說(shuō)是非常重要。

所以一套這樣的架構(gòu)是由這樣的3類角色共同組建而成。每個(gè)部分的解釋如下：

1.TiDB Server

TiDB Server 負(fù)責(zé)接收 SQL 請(qǐng)求，處理 SQL 相關(guān)的邏輯，并通過(guò) PD 找到存儲(chǔ)計(jì)算所需數(shù)據(jù)的 TiKV 地址，與 TiKV 交互獲取數(shù)據(jù)，最終返回結(jié)果。TiDB Server 是無(wú)狀態(tài)的，其本身并不存儲(chǔ)數(shù)據(jù)，只負(fù)責(zé)計(jì)算，可以無(wú)限水平擴(kuò)展，可以通過(guò)負(fù)載均衡組件（如LVS、HAProxy 或 F5）對(duì)外提供統(tǒng)一的接入地址。

2.PD Server

Placement Driver (簡(jiǎn)稱 PD) 是整個(gè)集群的管理模塊，其主要工作有三個(gè)：一是存儲(chǔ)集群的元信息（某個(gè) Key 存儲(chǔ)在哪個(gè) TiKV 節(jié)點(diǎn)）；二是對(duì) TiKV 集群進(jìn)行調(diào)度和負(fù)載均衡（如數(shù)據(jù)的遷移、Raft group leader 的遷移等）；三是分配全局唯一且遞增的事務(wù) ID。PD 是一個(gè)集群，需要部署奇數(shù)個(gè)節(jié)點(diǎn)，一般線上推薦至少部署 3 個(gè)節(jié)點(diǎn)。

3.TiKV Server

TiKV Server 負(fù)責(zé)存儲(chǔ)數(shù)據(jù)，從外部看 TiKV 是一個(gè)分布式的提供事務(wù)的 Key-Value 存儲(chǔ)引擎。存儲(chǔ)數(shù)據(jù)的基本單位是 Region，每個(gè) Region 負(fù)責(zé)存儲(chǔ)一個(gè) Key Range （從 StartKey 到 EndKey 的左閉右開區(qū)間）的數(shù)據(jù)，每個(gè) TiKV 節(jié)點(diǎn)會(huì)負(fù)責(zé)多個(gè) Region 。TiKV 使用 Raft 協(xié)議做復(fù)制，保持?jǐn)?shù)據(jù)的一致性和容災(zāi)。副本以 Region 為單位進(jìn)行管理，不同節(jié)點(diǎn)上的多個(gè) Region 構(gòu)成一個(gè) Raft Group，互為副本。數(shù)據(jù)在多個(gè) TiKV 之間的負(fù)載均衡由 PD 調(diào)度，這里也是以 Region 為單位進(jìn)行調(diào)度。

TIDB五大核心特性

一鍵水平擴(kuò)縮容

得益于 TiDB 存儲(chǔ)計(jì)算分離的架構(gòu)的設(shè)計(jì)，可按需對(duì)計(jì)算、存儲(chǔ)分別進(jìn)行在線擴(kuò)容或者縮容，擴(kuò)容或者縮容過(guò)程中對(duì)應(yīng)用運(yùn)維人員透明。

金融級(jí)高可用

數(shù)據(jù)采用多副本存儲(chǔ)，數(shù)據(jù)副本通過(guò) Multi-Raft 協(xié)議同步事務(wù)日志，多數(shù)派寫入成功事務(wù)才能提交，確保數(shù)據(jù)強(qiáng)一致性且少數(shù)副本發(fā)生故障時(shí)不影響數(shù)據(jù)的可用性?？砂葱枧渲酶北镜乩砦恢?、副本數(shù)量等策略滿足不同容災(zāi)級(jí)別的要求。

實(shí)時(shí)HTAP

提供行存儲(chǔ)引擎 TiKV、列存儲(chǔ)引擎 TiFlash 兩款存儲(chǔ)引擎，TiFlash 通過(guò) Multi-Raft Learner 協(xié)議實(shí)時(shí)從 TiKV 復(fù)制數(shù)據(jù)，確保行存儲(chǔ)引擎 TiKV 和列存儲(chǔ)引擎 TiFlash 之間的數(shù)據(jù)強(qiáng)一致。TiKV、TiFlash 可按需部署在不同的機(jī)器，解決 HTAP 資源隔離的問(wèn)題。

云原生的分布式數(shù)據(jù)庫(kù)

專為云而設(shè)計(jì)的分布式數(shù)據(jù)庫(kù)，通過(guò) TiDB Operator 可在公有云、私有云、混合云中實(shí)現(xiàn)部署工具化、自動(dòng)化。

兼容MYSQL5.7

專為云而設(shè)計(jì)的分布式數(shù)據(jù)庫(kù)，通過(guò) TiDB Operator 可在公有云、私有云、混合云中實(shí)現(xiàn)部署工具化、自動(dòng)化。

 

TIDB四大核心應(yīng)用場(chǎng)景

HTAP 給開發(fā)者提供了一個(gè)實(shí)時(shí)數(shù)據(jù)分析方面的新思路，不需要再去維護(hù)另一個(gè)離線的數(shù)據(jù)倉(cāng)庫(kù)，既減輕了 ETL 的工作，又能節(jié)省很大一部分建立數(shù)據(jù)倉(cāng)庫(kù)所用到的存儲(chǔ)和計(jì)算成本，HTAP 將是未來(lái)的重要趨勢(shì)。

黃東旭介紹了 TiDB 的四個(gè)主要應(yīng)用場(chǎng)景，一是 MySQL 分片與合并；二是直接替換 MySQL；三是用做數(shù)據(jù)倉(cāng)庫(kù)；四是作為其他系統(tǒng)的一個(gè)模塊。

MySQL分片與合并

Syncer：

TiDB 應(yīng)用的第一類場(chǎng)景是 MySQL 的分片與合并。對(duì)于已經(jīng)在用 MySQL 的業(yè)務(wù)，分庫(kù)、分表、分片、中間件是常用手段，隨著分片的增多，跨分片查詢是一大難題。TiDB 在業(yè)務(wù)層兼容 MySQL 的訪問(wèn)協(xié)議，PingCAP 做了一個(gè)數(shù)據(jù)同步的工具——Syncer，它可以把 TiDB 作為一個(gè) MySQL Slave，將 TiDB 作為現(xiàn)有數(shù)據(jù)庫(kù)的從庫(kù)接在主 MySQL 庫(kù)的后方，在這一層將數(shù)據(jù)打通，可以直接進(jìn)行復(fù)雜的跨庫(kù)、跨表、跨業(yè)務(wù)的實(shí)時(shí) SQL 查詢。黃東旭提到，過(guò)去的數(shù)據(jù)庫(kù)都是一主多從，有了 TiDB 以后，可以反過(guò)來(lái)做到多主一從。

 

替換MySQL

第二類場(chǎng)景是用 TiDB 直接去替換 MySQL。如果你的IT架構(gòu)在搭建之初并未考慮分庫(kù)分表的問(wèn)題，全部用了 MySQL，隨著業(yè)務(wù)的快速增長(zhǎng)，海量高并發(fā)的 OLTP 場(chǎng)景越來(lái)越多，如何解決架構(gòu)上的弊端呢?

在一個(gè) TiDB 的數(shù)據(jù)庫(kù)上，所有業(yè)務(wù)場(chǎng)景不需要做分庫(kù)分表，所有的分布式工作都由數(shù)據(jù)庫(kù)層完成。TiDB 兼容 MySQL 協(xié)議，所以可以直接替換 MySQL，而且基本做到了開箱即用，完全不用擔(dān)心傳統(tǒng)分庫(kù)分表方案帶來(lái)繁重的工作負(fù)擔(dān)和復(fù)雜的維護(hù)成本，友好的用戶界面讓常規(guī)的技術(shù)人員可以高效地進(jìn)行維護(hù)和管理。另外，TiDB 具有 NoSQL 類似的擴(kuò)容能力，在數(shù)據(jù)量和訪問(wèn)流量持續(xù)增長(zhǎng)的情況下能夠通過(guò)水平擴(kuò)容提高系統(tǒng)的業(yè)務(wù)支撐能力，并且響應(yīng)延遲穩(wěn)定。

黃東旭在演講中提到了摩拜單車的案例，摩拜早期的數(shù)據(jù)庫(kù)全部用 MySQL，隨著業(yè)務(wù)的快速增長(zhǎng)，MySQL 的弊端逐漸顯現(xiàn)，摩拜單車于 2017 年初開始使用 TiDB 替換 MySQL。如今，摩拜的 IT 系統(tǒng)中已部署了數(shù)套 TiDB 集群，近百個(gè)節(jié)點(diǎn)，承載著數(shù)十 TB 的各類數(shù)據(jù)。

數(shù)據(jù)倉(cāng)庫(kù)

TiDB 本身是一個(gè)分布式系統(tǒng)，第三種使用場(chǎng)景是將 TiDB 當(dāng)作數(shù)據(jù)倉(cāng)庫(kù)使用。TPC-H 是數(shù)據(jù)分析領(lǐng)域的一個(gè)測(cè)試集，TiDB 2.0 在 OLAP 場(chǎng)景下的性能有了大幅提升，原來(lái)只能在數(shù)據(jù)倉(cāng)庫(kù)里面跑的一些復(fù)雜的 Query，在 TiDB 2.0 里面跑，時(shí)間基本都能控制在 10 秒以內(nèi)。當(dāng)然，因?yàn)?OLAP 的范疇非常大，TiDB 的 SQL 也有搞不定的情況，為此 PingCAP 開源了 TiSpark，TiSpark 是一個(gè) Spark 插件，用戶可以直接用 Spark SQL 實(shí)時(shí)地在 TiKV 上做大數(shù)據(jù)分析。

作為其他系統(tǒng)的模塊

TiDB 是一個(gè)傳統(tǒng)的存儲(chǔ)跟計(jì)算分離的項(xiàng)目，其底層的 Key-Value 層，可以單獨(dú)作為一個(gè) HBase 的 Replacement 來(lái)用，它同時(shí)支持跨行事務(wù)。TiDB 對(duì)外提供兩個(gè) API 接口，一個(gè)是 ACID Transaction 的 API，用于支持跨行事務(wù)；另一個(gè)是 Raw API，它可以做單行的事務(wù)，換來(lái)的是整個(gè)性能的提升，但不提供跨行事務(wù)的 ACID 支持。用戶可以根據(jù)自身的需求在兩個(gè) API 之間自行選擇。例如有一些用戶直接在 TiKV 之上實(shí)現(xiàn)了 Redis 協(xié)議，將 TiKV 替換一些大容量，對(duì)延遲要求不高的 Redis 場(chǎng)景。

 

與MySQL兼容性對(duì)比

TiDB 支持包括跨行事務(wù)，JOIN 及子查詢?cè)趦?nèi)的絕大多數(shù) MySQL 的語(yǔ)法，用戶可以直接使用現(xiàn)有的 MySQL 客戶端連接。如果現(xiàn)有的業(yè)務(wù)已經(jīng)基于 MySQL 開發(fā)，大多數(shù)情況不需要修改代碼即可直接替換單機(jī)的 MySQL。

包括現(xiàn)有的大多數(shù) MySQL 運(yùn)維工具（如 PHPMyAdmin, Navicat, MySQL Workbench 等），以及備份恢復(fù)工具（如 mysqldump, mydumper/myloader）等都可以直接使用。

不過(guò)一些特性由于在分布式環(huán)境下沒(méi)法很好的實(shí)現(xiàn)，目前暫時(shí)不支持或者是表現(xiàn)與 MySQL 有差異。

一些 MySQL 語(yǔ)法在 TiDB中可以解析通過(guò)，但是不會(huì)做任何后續(xù)的處理，例如 Create Table 語(yǔ)句中 Engine 以及 Partition 選項(xiàng)，都是解析并忽略。

不支持的特性有以下這些：

存儲(chǔ)過(guò)程，視圖，觸發(fā)器，自定義函數(shù)，外鍵約束，全文索引，空間索引，非 UTF8 字符集等

 

總結(jié)

本文帶你了解了TIDB這款分布式數(shù)據(jù)庫(kù)，它的特性，應(yīng)用場(chǎng)景以及與MySQl的兼容性對(duì)比，下篇將會(huì)介紹TIDB的部署搭建，計(jì)算，存儲(chǔ)，調(diào)度方面的知識(shí)！

假如面試中你被問(wèn)到這些，我相信你看了這篇一定能撥動(dòng)面試官的心！

有道無(wú)術(shù)，術(shù)可成；有術(shù)無(wú)道，止于術(shù)

歡迎大家關(guān)注Java之道公眾號(hào)

好文章，我在看??