如今硬件的性價(jià)比越來越高誊涯，網(wǎng)絡(luò)傳輸速度越來越快迹蛤，數(shù)據(jù)庫分層的趨勢逐漸顯現(xiàn)奇颠，人們已經(jīng)不再強(qiáng)求用一個(gè)解決方案來解決所有的存儲問題败去，而是通過分層，讓緩存與數(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ù)的前提下躁锁，能夠彈性伸縮纷铣，高可用，可以同時(shí)處理 OLTP 和 OLAP 工作負(fù)載战转，不再需要 ETL搜立。
TiDB 產(chǎn)品的整體架構(gòu)是高度分層的，由分布式 SQL 層（TiDB）槐秧、分布式 KV 存儲引擎（TiKV）以及管理整個(gè)集群的 PD 模塊組成啄踊。無限水平擴(kuò)展是 TiDB 的一大特點(diǎn)忧设，這里所說的水平擴(kuò)展包括兩方面：計(jì)算能力和存儲能力。
HTAP 給開發(fā)者提供了一個(gè)實(shí)時(shí)數(shù)據(jù)分析方面的新思路颠通，不需要再去維護(hù)另一個(gè)離線的數(shù)據(jù)倉庫址晕，既減輕了 ETL 的工作，又能節(jié)省很大一部分建立數(shù)據(jù)倉庫所用到的存儲和計(jì)算成本蒜哀，HTAP 將是未來的重要趨勢斩箫。黃東旭介紹了 TiDB 的四個(gè)主要應(yīng)用場景，一是 MySQL 分片與合并撵儿；二是直接替換 MySQL乘客；三是用做數(shù)據(jù)倉庫；四是作為其他系統(tǒng)的一個(gè)模塊淀歇。
TiDB 應(yīng)用的第一類場景是 MySQL 的分片與合并易核。對于已經(jīng)在用 MySQL 的業(yè)務(wù)，分庫浪默、分表牡直、分片、中間件是常用手段纳决，隨著分片的增多碰逸，跨分片查詢是一大難題。TiDB 在業(yè)務(wù)層兼容 MySQL 的訪問協(xié)議阔加，PingCAP 做了一個(gè)數(shù)據(jù)同步的工具——Syncer饵史，它可以把 TiDB 作為一個(gè) MySQL Slave，將 TiDB 作為現(xiàn)有數(shù)據(jù)庫的從庫接在主 MySQL 庫的后方胜榔，在這一層將數(shù)據(jù)打通胳喷，可以直接進(jìn)行復(fù)雜的跨庫、跨表夭织、跨業(yè)務(wù)的實(shí)時(shí) SQL 查詢吭露。黃東旭提到，“過去的數(shù)據(jù)庫都是一主多從尊惰，有了 TiDB 以后讲竿，可以反過來做到多主一從∨牛”
第二類場景是用 TiDB 直接去替換 MySQL题禀。如果你的IT架構(gòu)在搭建之初并未考慮分庫分表的問題，全部用了 MySQL琢岩，隨著業(yè)務(wù)的快速增長投剥，海量高并發(fā)的 OLTP 場景越來越多，如何解決架構(gòu)上的弊端呢?
在一個(gè) 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 集群，近百個(gè)節(jié)點(diǎn)吹害，承載著數(shù)十 TB 的各類數(shù)據(jù)螟凭。
TiDB 本身是一個(gè)分布式系統(tǒng)，第三種使用場景是將 TiDB 當(dāng)作數(shù)據(jù)倉庫使用它呀。TPC-H 是數(shù)據(jù)分析領(lǐng)域的一個(gè)測試集螺男，TiDB 2.0 在 OLAP 場景下的性能有了大幅提升，原來只能在數(shù)據(jù)倉庫里面跑的一些復(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ù)分析宪赶。
TiDB 是一個(gè)傳統(tǒng)的存儲跟計(jì)算分離的項(xiàng)目宗弯，其底層的 Key-Value 層，可以單獨(dú)作為一個(gè) HBase 的 Replacement 來用搂妻，它同時(shí)支持跨行事務(wù)蒙保。TiDB 對外提供兩個(gè) API 接口，一個(gè)是 ACID Transaction 的 API欲主，用于支持跨行事務(wù)邓厕；另一個(gè)是 Raw API逝嚎，它可以做單行的事務(wù)，換來的是整個(gè)性能的提升详恼，但不提供跨行事務(wù)的 ACID 支持补君。用戶可以根據(jù)自身的需求在兩個(gè) API 之間自行選擇。例如有一些用戶直接在 TiKV 之上實(shí)現(xiàn)了 Redis 協(xié)議昧互，將 TiKV 替換一些大容量挽铁，對延遲要求不高的 Redis 場景。
