TiDB 數(shù)據(jù)庫的 4 大應(yīng)用場景分析
點(diǎn)擊上方藍(lán)色“程序猿DD”，選擇“設(shè)為星標(biāo)”
回復(fù)“資源”獲取獨(dú)家整理的學(xué)習(xí)資料！
如今硬件的性價比越來越高，網(wǎng)絡(luò)傳輸速度越來越快，數(shù)據(jù)庫分層的趨勢逐漸顯現(xiàn)，人們已經(jīng)不再強(qiáng)求用一個解決方案來解決所有的存儲問題，而是通過分層，讓緩存與數(shù)據(jù)庫負(fù)責(zé)各自擅長的業(yè)務(wù)場景。
黃東旭提到，當(dāng)前數(shù)據(jù)庫領(lǐng)域面臨各種問題，如在縮放、一致性、大數(shù)據(jù)分析、與云基礎(chǔ)架構(gòu)集成等方面均存在諸多問題，現(xiàn)有的數(shù)據(jù)庫解決方案和大數(shù)據(jù)分析引擎解決方案基本處于割裂的狀態(tài)，由于 Oracle、MySQL 數(shù)據(jù)庫并不是面向分布式環(huán)境而設(shè)計(jì)，因此即使勉強(qiáng)通過分庫、分表或中間件的方式，在數(shù)據(jù)庫層面做了分片，從本質(zhì)上看也只是復(fù)制了相同的堆棧，而非針對分布式系統(tǒng)進(jìn)行存儲和計(jì)算優(yōu)化，這正是進(jìn)行跨業(yè)務(wù)查詢或跨物理機(jī)查詢和寫入十分繁瑣的本質(zhì)原因。NoSQL 雖然解決了數(shù)據(jù)庫彈性擴(kuò)展的難題，但是卻放棄了數(shù)據(jù)的強(qiáng)一致性以及對 ACID 事務(wù)的支持，帶來了新的問題。
為了解決這一問題，TiDB 在架構(gòu)上將計(jì)算和存儲層進(jìn)行高度的抽象和分離，對混合負(fù)載的場景通過 IO 優(yōu)先級隊(duì)列，智能副本調(diào)度，行列混合存儲等技術(shù)使其變?yōu)榭赡堋iDB 作為開源的分布式關(guān)系數(shù)據(jù)庫，其特點(diǎn)是幾乎可以 100% 兼容 MySQL 接口，也兼容 MySQL 的語法和協(xié)議，在保證不喪失 ACID 事務(wù)的前提下，能夠彈性伸縮，高可用，可以同時處理 OLTP 和 OLAP 工作負(fù)載，不再需要 ETL。
TiDB整體架構(gòu)圖
TiDB 產(chǎn)品的整體架構(gòu)是高度分層的，由分布式 SQL 層（TiDB）、分布式 KV 存儲引擎（TiKV）以及管理整個集群的 PD 模塊組成。無限水平擴(kuò)展是 TiDB 的一大特點(diǎn)，這里所說的水平擴(kuò)展包括兩方面：計(jì)算能力和存儲能力。
HTAP 給開發(fā)者提供了一個實(shí)時數(shù)據(jù)分析方面的新思路，不需要再去維護(hù)另一個離線的數(shù)據(jù)倉庫，既減輕了 ETL 的工作，又能節(jié)省很大一部分建立數(shù)據(jù)倉庫所用到的存儲和計(jì)算成本，HTAP 將是未來的重要趨勢。黃東旭介紹了 TiDB 的四個主要應(yīng)用場景，一是 MySQL 分片與合并；二是直接替換 MySQL；三是用做數(shù)據(jù)倉庫；四是作為其他系統(tǒng)的一個模塊。
用例 1：MySQL 分片與合并
Syncer
TiDB 應(yīng)用的第一類場景是 MySQL 的分片與合并。對于已經(jīng)在用 MySQL 的業(yè)務(wù)，分庫、分表、分片、中間件是常用手段，隨著分片的增多，跨分片查詢是一大難題。TiDB 在業(yè)務(wù)層兼容 MySQL 的訪問協(xié)議，PingCAP 做了一個數(shù)據(jù)同步的工具——Syncer，它可以把 TiDB 作為一個 MySQL Slave，將 TiDB 作為現(xiàn)有數(shù)據(jù)庫的從庫接在主 MySQL 庫的后方，在這一層將數(shù)據(jù)打通，可以直接進(jìn)行復(fù)雜的跨庫、跨表、跨業(yè)務(wù)的實(shí)時 SQL 查詢。黃東旭提到，“過去的數(shù)據(jù)庫都是一主多從，有了 TiDB 以后，可以反過來做到多主一從。”
用例 2：直接替換 MySQL
第二類場景是用 TiDB 直接去替換 MySQL。如果你的IT架構(gòu)在搭建之初并未考慮分庫分表的問題，全部用了 MySQL，隨著業(yè)務(wù)的快速增長，海量高并發(fā)的 OLTP 場景越來越多，如何解決架構(gòu)上的弊端呢?
在一個 TiDB 的數(shù)據(jù)庫上，所有業(yè)務(wù)場景不需要做分庫分表，所有的分布式工作都由數(shù)據(jù)庫層完成。TiDB 兼容 MySQL 協(xié)議，所以可以直接替換 MySQL，而且基本做到了開箱即用，完全不用擔(dān)心傳統(tǒng)分庫分表方案帶來繁重的工作負(fù)擔(dān)和復(fù)雜的維護(hù)成本，友好的用戶界面讓常規(guī)的技術(shù)人員可以高效地進(jìn)行維護(hù)和管理。另外，TiDB 具有 NoSQL 類似的擴(kuò)容能力，在數(shù)據(jù)量和訪問流量持續(xù)增長的情況下能夠通過水平擴(kuò)容提高系統(tǒng)的業(yè)務(wù)支撐能力，并且響應(yīng)延遲穩(wěn)定。
黃東旭在演講中提到了摩拜單車的案例，摩拜早期的數(shù)據(jù)庫全部用 MySQL，隨著業(yè)務(wù)的快速增長，MySQL 的弊端逐漸顯現(xiàn)，摩拜單車于 2017 年初開始使用 TiDB 替換 MySQL。如今，摩拜的 IT 系統(tǒng)中已部署了數(shù)套 TiDB 集群，近百個節(jié)點(diǎn)，承載著數(shù)十 TB 的各類數(shù)據(jù)。
用例 3：數(shù)據(jù)倉庫
TiDB 本身是一個分布式系統(tǒng)，第三種使用場景是將 TiDB 當(dāng)作數(shù)據(jù)倉庫使用。TPC-H 是數(shù)據(jù)分析領(lǐng)域的一個測試集，TiDB 2.0 在 OLAP 場景下的性能有了大幅提升，原來只能在數(shù)據(jù)倉庫里面跑的一些復(fù)雜的 Query，在 TiDB 2.0 里面跑，時間基本都能控制在 10 秒以內(nèi)。當(dāng)然，因?yàn)?OLAP 的范疇非常大，TiDB 的 SQL 也有搞不定的情況，為此 PingCAP 開源了 TiSpark，TiSpark 是一個 Spark 插件，用戶可以直接用 Spark SQL 實(shí)時地在 TiKV 上做大數(shù)據(jù)分析。
用例 4：作為其他系統(tǒng)的模塊
TiDB 是一個傳統(tǒng)的存儲跟計(jì)算分離的項(xiàng)目，其底層的 Key-Value 層，可以單獨(dú)作為一個 HBase 的 Replacement 來用，它同時支持跨行事務(wù)。TiDB 對外提供兩個 API 接口，一個是 ACID Transaction 的 API，用于支持跨行事務(wù)；另一個是 Raw API，它可以做單行的事務(wù)，換來的是整個性能的提升，但不提供跨行事務(wù)的 ACID 支持。用戶可以根據(jù)自身的需求在兩個 API 之間自行選擇。例如有一些用戶直接在 TiKV 之上實(shí)現(xiàn)了 Redis 協(xié)議，將 TiKV 替換一些大容量，對延遲要求不高的 Redis 場景。
更多關(guān)于數(shù)據(jù)庫的學(xué)習(xí)
推薦關(guān)注下方公眾號
【往期推薦】
2020-11-26
2020-11-25
2020-11-24
2020-11-23
2020-11-22
﹀
﹀
﹀
深度內(nèi)容
推薦加入
