建站
咨詢
售后
建站咨詢
新聞中心
TiDB 是一個(gè)分布式 NewSQL 數(shù)據(jù)庫。它支持水平彈性擴(kuò)展、ACID 事務(wù)、標(biāo)準(zhǔn) SQL、MySQL 語法和 MySQL 協(xié)議，具有數(shù)據(jù)強(qiáng)一致的高可用特性，是一個(gè)不僅適合 OLTP 場景還適合 OLAP 場景的混合數(shù)據(jù)庫。
創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比殷都網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式殷都網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋殷都地區(qū)。費(fèi)用合理售后完善，十年實(shí)體公司更值得信賴。
TiDB是 PingCAP公司自主設(shè)計(jì)、研發(fā)的開源分布式關(guān)系型數(shù)據(jù)庫，是一款同時(shí)支持在線事務(wù)處理與在線分析處理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分布式數(shù)據(jù)庫產(chǎn)品，具備水平擴(kuò)容或者縮容、金融級(jí)高可用、實(shí)時(shí) HTAP、云原生的分布式數(shù)據(jù)庫、兼容 MySQL 5.7 協(xié)議和 MySQL 生態(tài)等重要特性。目標(biāo)是為用戶提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解決方案。TiDB 適合高可用、強(qiáng)一致要求較高、數(shù)據(jù)規(guī)模較大等各種應(yīng)用場景。
什么是NewSQL
數(shù)據(jù)庫發(fā)展至今已經(jīng)有3代了：
- SQL，傳統(tǒng)關(guān)系型數(shù)據(jù)庫，例如 MySQL
- noSQL，例如 MongoDB,Redis
- newSQL
傳統(tǒng)SQL的問題
互聯(lián)網(wǎng)在本世紀(jì)初開始迅速發(fā)展，互聯(lián)網(wǎng)應(yīng)用的用戶規(guī)模、數(shù)據(jù)量都越來越大，并且要求7X24小時(shí)在線。
傳統(tǒng)關(guān)系型數(shù)據(jù)庫在這種環(huán)境下成為了瓶頸，通常有2種解決方法：
升級(jí)服務(wù)器硬件
雖然提升了性能，但總有天花板。
數(shù)據(jù)分片
使用分布式集群結(jié)構(gòu)
對單點(diǎn)數(shù)據(jù)庫進(jìn)行數(shù)據(jù)分片，存放到由廉價(jià)機(jī)器組成的分布式的集群里，可擴(kuò)展性更好了，但也帶來了新的麻煩。
以前在一個(gè)庫里的數(shù)據(jù)，現(xiàn)在跨了多個(gè)庫，應(yīng)用系統(tǒng)不能自己去多個(gè)庫中操作，需要使用數(shù)據(jù)庫分片中間件。
分片中間件做簡單的數(shù)據(jù)操作時(shí)還好，但涉及到跨庫join、跨庫事務(wù)時(shí)就很頭疼了，很多人干脆自己在業(yè)務(wù)層處理，復(fù)雜度較高。
NoSQL 的問題
后來 noSQL 出現(xiàn)了，放棄了傳統(tǒng)SQL的強(qiáng)事務(wù)保證和關(guān)系模型，重點(diǎn)放在數(shù)據(jù)庫的高可用性和可擴(kuò)展性。
優(yōu)點(diǎn)
- 高可用性和可擴(kuò)展性，自動(dòng)分區(qū)，輕松擴(kuò)展
- 不保證強(qiáng)一致性，性能大幅提升
- 沒有關(guān)系模型的限制，極其靈活
缺點(diǎn)
- 不保證強(qiáng)一致性，對于普通應(yīng)用沒問題，但還是有不少像金融一樣的企業(yè)級(jí)應(yīng)用有強(qiáng)一致性的需求。
- 不支持 SQL 語句，兼容性是個(gè)大問題，不同的 NoSQL 數(shù)據(jù)庫都有自己的 api 操作數(shù)據(jù)，比較復(fù)雜。
NewSQL 特性
NewSQL 提供了與 noSQL 相同的可擴(kuò)展性，而且仍基于關(guān)系模型，還保留了極其成熟的 SQL 作為查詢語言，保證了ACID事務(wù)特性。
簡單來講，NewSQL 就是在傳統(tǒng)關(guān)系型數(shù)據(jù)庫上集成了 NoSQL 強(qiáng)大的可擴(kuò)展性。
傳統(tǒng)的SQL架構(gòu)設(shè)計(jì)基因中是沒有分布式的，而 NewSQL 生于云時(shí)代，天生就是分布式架構(gòu)。
NewSQL 的主要特性
- SQL 支持，支持復(fù)雜查詢和大數(shù)據(jù)分析。
- 支持 ACID 事務(wù)，支持隔離級(jí)別。
- 彈性伸縮，擴(kuò)容縮容對于業(yè)務(wù)層完全透明。
- 高可用，自動(dòng)容災(zāi)。
三種SQL的對比
TiDB怎么來的
著名的開源分布式緩存服務(wù) Codis 的作者，PingCAP聯(lián)合創(chuàng)始人& CTO ，資深 infrastructure 工程師的黃東旭，擅長分布式存儲(chǔ)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)，開源狂熱分子的技術(shù)大神級(jí)別人物。即使在互聯(lián)網(wǎng)如此繁榮的今天，在數(shù)據(jù)庫這片邊界模糊且不確定地帶，他還在努力尋找確定性的實(shí)踐方向。關(guān)注公z號(hào)：碼猿技術(shù)專欄，回復(fù)關(guān)鍵詞：1111 獲取阿里內(nèi)部Java性能優(yōu)化手冊！
直到 2012 年底，他看到 Google 發(fā)布的兩篇論文，如同棱鏡般，折射出他自己內(nèi)心微爍的光彩。這兩篇論文描述了 Google 內(nèi)部使用的一個(gè)海量關(guān)系型數(shù)據(jù)庫 F1/Spanner ，解決了關(guān)系型數(shù)據(jù)庫、彈性擴(kuò)展以及全球分布的問題，并在生產(chǎn)中大規(guī)模使用。“如果這個(gè)能實(shí)現(xiàn)，對數(shù)據(jù)存儲(chǔ)領(lǐng)域來說將是顛覆性的”，黃東旭為完美方案的出現(xiàn)而興奮， PingCAP 的 TiDB 在此基礎(chǔ)上誕生了。
TiDB社區(qū)版和企業(yè)版
TiDB分為社區(qū)版以及企業(yè)版，企業(yè)版收費(fèi)提供服務(wù)以及安全性的支持
TIDB核心特性
水平彈性擴(kuò)展
通過簡單地增加新節(jié)點(diǎn)即可實(shí)現(xiàn) TiDB 的水平擴(kuò)展，按需擴(kuò)展吞吐或存儲(chǔ)，輕松應(yīng)對高并發(fā)、海量數(shù)據(jù)場景
得益于 TiDB 存儲(chǔ)計(jì)算分離的架構(gòu)的設(shè)計(jì)，可按需對計(jì)算、存儲(chǔ)分別進(jìn)行在線擴(kuò)容或者縮容，擴(kuò)容或者縮容過程中對應(yīng)用運(yùn)維人員透明。
分布式事務(wù)支持
TiDB 100% 支持標(biāo)準(zhǔn)的 ACID 事務(wù)
金融級(jí)高可用
相比于傳統(tǒng)主從 (M-S) 復(fù)制方案，基于 Raft 的多數(shù)派選舉協(xié)議可以提供金融級(jí)的 100% 數(shù)據(jù)強(qiáng)一致性保證，且在不丟失大多數(shù)副本的前提下，可以實(shí)現(xiàn)故障的自動(dòng)恢復(fù)(auto-failover)，無需人工介入
數(shù)據(jù)采用多副本存儲(chǔ)，數(shù)據(jù)副本通過 Multi-Raft 協(xié)議同步事務(wù)日志，多數(shù)派寫入成功事務(wù)才能提交，確保數(shù)據(jù)強(qiáng)一致性且少數(shù)副本發(fā)生故障時(shí)不影響數(shù)據(jù)的可用性?？砂葱枧渲酶北镜乩砦恢谩⒏北緮?shù)量等策略滿足不同容災(zāi)級(jí)別的要求。
實(shí)時(shí) HTAP
TiDB 作為典型的 OLTP 行存數(shù)據(jù)庫，同時(shí)兼具強(qiáng)大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解決方案，一份存儲(chǔ)同時(shí)處理 OLTP & OLAP 無需傳統(tǒng)繁瑣的 ETL 過程
提供行存儲(chǔ)引擎 TiKV、列存儲(chǔ)引擎 TiFlash 兩款存儲(chǔ)引擎，TiFlash 通過 Multi-Raft Learner 協(xié)議實(shí)時(shí)從 TiKV 復(fù)制數(shù)據(jù)，確保行存儲(chǔ)引擎 TiKV 和列存儲(chǔ)引擎 TiFlash 之間的數(shù)據(jù)強(qiáng)一致。TiKV、TiFlash 可按需部署在不同的機(jī)器，解決 HTAP 資源隔離的問題。
云原生的分布式數(shù)據(jù)庫
TiDB 是為云而設(shè)計(jì)的數(shù)據(jù)庫，同 Kubernetes 深度耦合，支持公有云、私有云和混合云，使部署、配置和維護(hù)變得十分簡單。TiDB 的設(shè)計(jì)目標(biāo)是 100% 的 OLTP 場景和 80% 的 OLAP 場景，更復(fù)雜的 OLAP 分析可以通過 TiSpark 項(xiàng)目來完成。TiDB 對業(yè)務(wù)沒有任何侵入性，能優(yōu)雅的替換傳統(tǒng)的數(shù)據(jù)庫中間件、數(shù)據(jù)庫分庫分表等 Sharding 方案。同時(shí)它也讓開發(fā)運(yùn)維人員不用關(guān)注數(shù)據(jù)庫 Scale 的細(xì)節(jié)問題，專注于業(yè)務(wù)開發(fā)，極大的提升研發(fā)的生產(chǎn)力
高度兼容 MySQL
兼容 MySQL 5.7 協(xié)議、MySQL 常用的功能、MySQL 生態(tài)，應(yīng)用無需或者修改少量代碼即可從 MySQL 遷移到 TiDB。
提供豐富的數(shù)據(jù)遷移工具幫助應(yīng)用便捷完成數(shù)據(jù)遷移，大多數(shù)情況下，無需修改代碼即可從 MySQL 輕松遷移至 TiDB，分庫分表后的 MySQL 集群亦可通過 TiDB 工具進(jìn)行實(shí)時(shí)遷移。
OLTP&OLAP(自學(xué))
OLTP(聯(lián)機(jī)事務(wù)處理)
OLTP(Online Transactional Processing) 即聯(lián)機(jī)事務(wù)處理，OLTP 是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫的主要應(yīng)用，主要是基本的、日常的事務(wù)處理，記錄即時(shí)的增、刪、改、查，比如在銀行存取一筆款，就是一個(gè)事務(wù)交易
聯(lián)機(jī)事務(wù)處理是事務(wù)性非常高的系統(tǒng)，一般都是高可用的在線系統(tǒng)，以小的事務(wù)以及小的查詢?yōu)橹?，評(píng)估其系統(tǒng)的時(shí)候，一般看其每秒執(zhí)行的Transaction以及Execute SQL的數(shù)量。在這樣的系統(tǒng)中，單個(gè)數(shù)據(jù)庫每秒處理的Transaction往往超過幾百個(gè)，或者是幾千個(gè)，Select 語句的執(zhí)行量每秒幾千甚至幾萬個(gè)。典型的OLTP系統(tǒng)有電子商務(wù)系統(tǒng)、銀行、證券等，如美國eBay的業(yè)務(wù)數(shù)據(jù)庫，就是很典型的OLTP數(shù)據(jù)庫。
OLAP(聯(lián)機(jī)分析處理)
OLAP(Online Analytical Processing) 即聯(lián)機(jī)分析處理，是數(shù)據(jù)倉庫的核心部心，支持復(fù)雜的分析操作，側(cè)重決策支持，并且提供直觀易懂的查詢結(jié)果。典型的應(yīng)用就是復(fù)雜的動(dòng)態(tài)報(bào)表系統(tǒng)
在這樣的系統(tǒng)中，語句的執(zhí)行量不是考核標(biāo)準(zhǔn)，因?yàn)橐粭l語句的執(zhí)行時(shí)間可能會(huì)非常長，讀取的數(shù)據(jù)也非常多。所以，在這樣的系統(tǒng)中，考核的標(biāo)準(zhǔn)往往是磁盤子系統(tǒng)的吞吐量（帶寬），如能達(dá)到多少M(fèi)B/s的流量。
特性對比
OLTP和OLAP的特性對比
|
— |
OLTP |
OLAP |
|
實(shí)時(shí)性 |
OLTP 實(shí)時(shí)性要求高，OLTP 數(shù)據(jù)庫旨在使事務(wù)應(yīng)用程序僅寫入所需的數(shù)據(jù)，以便盡快處理單個(gè)事務(wù) |
OLAP 的實(shí)時(shí)性要求不是很高，很多應(yīng)用頂多是每天更新一下數(shù)據(jù) |
|
數(shù)據(jù)量 |
OLTP 數(shù)據(jù)量不是很大，一般只讀 / 寫數(shù)十條記錄，處理簡單的事務(wù) |
OLAP 數(shù)據(jù)量大，因?yàn)?OLAP 支持的是動(dòng)態(tài)查詢，所以用戶也許要通過將很多數(shù)據(jù)的統(tǒng)計(jì)后才能得到想要知道的信息，例如時(shí)間序列分析等等，所以處理的數(shù)據(jù)量很大 |
|
用戶和系統(tǒng)的面向性 |
OLTP 是面向顧客的，用于事務(wù)和查詢處理 |
OLAP 是面向市場的，用于數(shù)據(jù)分析 |
|
數(shù)據(jù)庫設(shè)計(jì) |
OLTP 采用實(shí)體 - 聯(lián)系 ER 模型和面向應(yīng)用的數(shù)據(jù)庫設(shè)計(jì) |
OLAP 采用星型或雪花模型和面向主題的數(shù)據(jù)庫設(shè)計(jì) |
設(shè)計(jì)角度區(qū)別
|
— |
OLTP |
OLAP |
|
用戶 |
操作人員，低層管理人員 |
決策人員，高級(jí)管理人員 |
|
功能 |
日常操作處理 |
分析決策 |
|
主要工作 |
增、刪、改 |
查詢 |
|
DB 設(shè)計(jì) |
面向應(yīng)用 |
面向主題 |
|
數(shù)據(jù) |
當(dāng)前的，最新的細(xì)節(jié)，二維的，分立的 |
歷史的，聚集的，多維集成的，統(tǒng)一的 |
|
存取 |
讀/寫數(shù)十條記錄 |
讀上百萬條記錄 |
|
工作單位 |
簡單的事務(wù) |
復(fù)雜的查詢 |
|
用戶數(shù) |
上千個(gè) |
上百個(gè) |
|
DB 大小 |
100MB-GB |
100GB-TB |
TiDB 整體架構(gòu)
TiDB的優(yōu)勢
與傳統(tǒng)的單機(jī)數(shù)據(jù)庫相比，TiDB 具有以下優(yōu)勢：
- 純分布式架構(gòu)，擁有良好的擴(kuò)展性，支持彈性的擴(kuò)縮容
- 支持 SQL，對外暴露 MySQL 的網(wǎng)絡(luò)協(xié)議，并兼容大多數(shù) MySQL 的語法，在大多數(shù)場景下可以直接替換 MySQL
- 默認(rèn)支持高可用，在少數(shù)副本失效的情況下，數(shù)據(jù)庫本身能夠自動(dòng)進(jìn)行數(shù)據(jù)修復(fù)和故障轉(zhuǎn)移，對業(yè)務(wù)透明
- 支持 ACID 事務(wù)，對于一些有強(qiáng)一致需求的場景友好，例如：銀行轉(zhuǎn)賬
- 具有豐富的工具鏈生態(tài)，覆蓋數(shù)據(jù)遷移、同步、備份等多種場景
TiDB的組件
要深入了解 TiDB 的水平擴(kuò)展和高可用特點(diǎn)，首先需要了解 TiDB 的整體架構(gòu)。TiDB 集群主要包括三個(gè)核心組件：TiDB Server，PD Server 和 TiKV Server，此外，還有用于解決用戶復(fù)雜 OLAP 需求的 TiSpark 組件。關(guān)注公z號(hào)：碼猿技術(shù)專欄，回復(fù)關(guān)鍵詞：1111 獲取阿里內(nèi)部Java性能優(yōu)化手冊！
在內(nèi)核設(shè)計(jì)上，TiDB 分布式數(shù)據(jù)庫將整體架構(gòu)拆分成了多個(gè)模塊，各模塊之間互相通信，組成完整的 TiDB 系統(tǒng)。對應(yīng)的架構(gòu)圖如下：
architecture
TiDB Server
TiDB Server 負(fù)責(zé)接收 SQL 請求，處理 SQL 相關(guān)的邏輯，并通過 PD 找到存儲(chǔ)計(jì)算所需數(shù)據(jù)的 TiKV 地址，與 TiKV 交互獲取數(shù)據(jù)，最終返回結(jié)果。TiDB Server 是無狀態(tài)的，其本身并不存儲(chǔ)數(shù)據(jù)，只負(fù)責(zé)計(jì)算，可以無限水平擴(kuò)展，可以通過負(fù)載均衡組件（如 LVS、HAProxy 或 F5）對外提供統(tǒng)一的接入地址。
PD (Placement Driver) Server
Placement Driver (簡稱 PD) 是整個(gè)集群的管理模塊，其主要工作有三個(gè)：
- 一是存儲(chǔ)集群的元信息（某個(gè) Key 存儲(chǔ)在哪個(gè) TiKV 節(jié)點(diǎn)）；
- 二是對 TiKV 集群進(jìn)行調(diào)度和負(fù)載均衡（如數(shù)據(jù)的遷移、Raft group leader 的遷移等）；
- 三是分配全局唯一且遞增的事務(wù) ID。
PD 通過 Raft 協(xié)議保證數(shù)據(jù)的安全性。Raft 的 leader server 負(fù)責(zé)處理所有操作，其余的 PD server 僅用于保證高可用。建議部署奇數(shù)個(gè) PD 節(jié)點(diǎn)
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)度。
TiSpark
TiSpark 作為 TiDB 中解決用戶復(fù)雜 OLAP 需求的主要組件，將 Spark SQL 直接運(yùn)行在 TiDB 存儲(chǔ)層上，同時(shí)融合 TiKV 分布式集群的優(yōu)勢，并融入大數(shù)據(jù)社區(qū)生態(tài)。至此，TiDB 可以通過一套系統(tǒng)，同時(shí)支持 OLTP 與 OLAP，免除用戶數(shù)據(jù)同步的煩惱。
TiFlash
TiFlash 是一類特殊的存儲(chǔ)節(jié)點(diǎn)。和普通 TiKV 節(jié)點(diǎn)不一樣的是，在 TiFlash 內(nèi)部，數(shù)據(jù)是以列式的形式進(jìn)行存儲(chǔ)，主要的功能是為分析型的場景加速。
TiKV整體架構(gòu)
與傳統(tǒng)的整節(jié)點(diǎn)備份方式不同的，TiKV是將數(shù)據(jù)按照 key 的范圍劃分成大致相等的切片（下文統(tǒng)稱為 Region），每一個(gè)切片會(huì)有多個(gè)副本（通常是 3 個(gè)），其中一個(gè)副本是 Leader，提供讀寫服務(wù)。TiKV 通過 PD 對這些 Region 以及副本進(jìn)行調(diào)度，以保證數(shù)據(jù)和讀寫負(fù)載都均勻地分散在各個(gè) TiKV 上，這樣的設(shè)計(jì)保證了整個(gè)集群資源的充分利用并且可以隨著機(jī)器數(shù)量的增加水平擴(kuò)展。
Region分裂與合并
當(dāng)某個(gè) Region 的大小超過一定限制（默認(rèn)是 144MB）后，TiKV 會(huì)將它分裂為兩個(gè)或者更多個(gè) Region，以保證各個(gè) Region 的大小是大致接近的，這樣更有利于 PD 進(jìn)行調(diào)度決策。同樣，當(dāng)某個(gè) Region 因?yàn)榇罅康膭h除請求導(dǎo)致 Region 的大小變得更小時(shí)，TiKV 會(huì)將比較小的兩個(gè)相鄰 Region 合并為一個(gè)。
Region調(diào)度
Region 與副本之間通過 Raft 協(xié)議來維持?jǐn)?shù)據(jù)一致性，任何寫請求都只能在 Leader 上寫入，并且需要寫入多數(shù)副本后（默認(rèn)配置為 3 副本，即所有請求必須至少寫入兩個(gè)副本成功）才會(huì)返回客戶端寫入成功。
當(dāng) PD 需要把某個(gè) Region 的一個(gè)副本從一個(gè) TiKV 節(jié)點(diǎn)調(diào)度到另一個(gè)上面時(shí)，PD 會(huì)先為這個(gè) Raft Group 在目標(biāo)節(jié)點(diǎn)上增加一個(gè) Learner 副本（復(fù)制 Leader 的數(shù)據(jù)）。當(dāng)這個(gè) Learner 副本的進(jìn)度大致追上 Leader 副本時(shí)，Leader 會(huì)將它變更為 Follower，之后再移除操作節(jié)點(diǎn)的 Follower 副本，這樣就完成了 Region 副本的一次調(diào)度。
Leader 副本的調(diào)度原理也類似，不過需要在目標(biāo)節(jié)點(diǎn)的 Learner 副本變?yōu)?Follower 副本后，再執(zhí)行一次 Leader Transfer，讓該 Follower 主動(dòng)發(fā)起一次選舉成為新 Leader，之后新 Leader 負(fù)責(zé)刪除舊 Leader 這個(gè)副本。
分布式事務(wù)
TiKV 支持分布式事務(wù)，用戶（或者 TiDB）可以一次性寫入多個(gè) key-value 而不必關(guān)心這些 key-value 是否處于同一個(gè)數(shù)據(jù)切片 (Region) 上，TiKV 通過兩階段提交保證了這些讀寫請求的 ACID 約束。
高可用架構(gòu)
高可用是 TiDB 的另一大特點(diǎn)，TiDB/TiKV/PD 這三個(gè)組件都能容忍部分實(shí)例失效，不影響整個(gè)集群的可用性。下面分別說明這三個(gè)組件的可用性、單個(gè)實(shí)例失效后的后果以及如何恢復(fù)。
TiDB高可用
TiDB 是無狀態(tài)的，推薦至少部署兩個(gè)實(shí)例，前端通過負(fù)載均衡組件對外提供服務(wù)。當(dāng)單個(gè)實(shí)例失效時(shí)，會(huì)影響正在這個(gè)實(shí)例上進(jìn)行的 Session，從應(yīng)用的角度看，會(huì)出現(xiàn)單次請求失敗的情況，重新連接后即可繼續(xù)獲得服務(wù)。單個(gè)實(shí)例失效后，可以重啟這個(gè)實(shí)例或者部署一個(gè)新的實(shí)例。
PD高可用
PD 是一個(gè)集群，通過 Raft 協(xié)議保持?jǐn)?shù)據(jù)的一致性，單個(gè)實(shí)例失效時(shí)，如果這個(gè)實(shí)例不是 Raft 的 leader，那么服務(wù)完全不受影響；如果這個(gè)實(shí)例是 Raft 的 leader，會(huì)重新選出新的 Raft leader，自動(dòng)恢復(fù)服務(wù)。PD 在選舉的過程中無法對外提供服務(wù)，這個(gè)時(shí)間大約是3秒鐘。推薦至少部署三個(gè) PD 實(shí)例，單個(gè)實(shí)例失效后，重啟這個(gè)實(shí)例或者添加新的實(shí)例。
TiKV高可用
TiKV 是一個(gè)集群，通過 Raft 協(xié)議保持?jǐn)?shù)據(jù)的一致性（副本數(shù)量可配置，默認(rèn)保存三副本），并通過 PD 做負(fù)載均衡調(diào)度。單個(gè)節(jié)點(diǎn)失效時(shí)，會(huì)影響這個(gè)節(jié)點(diǎn)上存儲(chǔ)的所有 Region。對于 Region 中的 Leader 結(jié)點(diǎn)，會(huì)中斷服務(wù)，等待重新選舉；對于 Region 中的 Follower 節(jié)點(diǎn)，不會(huì)影響服務(wù)。當(dāng)某個(gè) TiKV 節(jié)點(diǎn)失效，并且在一段時(shí)間內(nèi)（默認(rèn) 10 分鐘）無法恢復(fù)，PD 會(huì)將其上的數(shù)據(jù)遷移到其他的 TiKV 節(jié)點(diǎn)上。
應(yīng)用場景
MySQL分片與合并
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 以后，可以反過來做到多主一從?！?/p>
直接替換MySQL
第二類場景是用 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ù)倉庫
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ù)分析。
作為其他系統(tǒng)的模塊
TiDB 是一個(gè)傳統(tǒng)的存儲(chǔ)跟計(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 場景。
應(yīng)用案例
TiDB與MySQL兼容性對比
- TiDB支持MySQL傳輸協(xié)議及其絕大多數(shù)的語法。這意味著您現(xiàn)有的MySQL連接器和客戶端都可以繼續(xù)使用。大多數(shù)情況下您現(xiàn)有的應(yīng)用都可以遷移至 TiDB，無需任何代碼修改。
- 當(dāng)前TiDB服務(wù)器官方支持的版本為MySQL 5.7。大部分MySQL運(yùn)維工具（如PHPMyAdmin, Navicat, MySQL Workbench等），以及備份恢復(fù)工具（如 mysqldump, Mydumper/myloader）等都可以直接使用。
- 不過一些特性由于在分布式環(huán)境下沒法很好的實(shí)現(xiàn)，目前暫時(shí)不支持或者是表現(xiàn)與MySQL有差異
- 一些MySQL語法在TiDB中可以解析通過，但是不會(huì)做任何后續(xù)的處理，例如Create Table語句中Engine，是解析并忽略。
TiDB不支持的MySql特性
- 存儲(chǔ)過程與函數(shù)
- 觸發(fā)器
- 事件
- 自定義函數(shù)
- 外鍵約束
- 臨時(shí)表
- 全文/空間函數(shù)與索引
- 非 ascii/latin1/binary/utf8/utf8mb4 的字符集
- SYS schema
- MySQL 追蹤優(yōu)化器
- XML 函數(shù)
- X-Protocol
- Savepoints
- 列級(jí)權(quán)限
- XA 語法（TiDB 內(nèi)部使用兩階段提交，但并沒有通過 SQL 接口公開）
- CREATE TABLE tblName AS SELECT stmt 語法
- CHECK TABLE 語法
- CHECKSUM TABLE 語法
- GET_LOCK? 和 RELEASE_LOCK 函數(shù)
自增ID
TiDB 的自增列僅保證唯一，也能保證在單個(gè) TiDB server 中自增，但不保證多個(gè) TiDB server 中自增，不保證自動(dòng)分配的值的連續(xù)性，建議不要將缺省值和自定義值混用，若混用可能會(huì)收 Duplicated Error 的錯(cuò)誤信息。
TiDB 可通過 tidb_allow_remove_auto_inc? 系統(tǒng)變量開啟或者關(guān)閉允許移除列的 AUTO_INCREMENT? 屬性。刪除列屬性的語法是：alter table modify? 或 alter table change。
TiDB 不支持添加列的 AUTO_INCREMENT 屬性，移除該屬性后不可恢復(fù)。
SELECT 的限制
- 不支持 SELECT ... INTO @變量 語法。
- 不支持 SELECT ... GROUP BY ... WITH ROLLUP 語法。
- TiDB 中的 SELECT .. GROUP BY expr 的返回結(jié)果與 MySQL 5.7 并不一致。MySQL 5.7 的結(jié)果等價(jià)于 GROUP BY expr ORDER BY expr。而 TiDB 中該語法所返回的結(jié)果并不承諾任何順序，與 MySQL 8.0 的行為一致。
視圖
目前TiDB不支持對視圖進(jìn)行UPDATE、INSERT、DELETE等寫入操作。
默認(rèn)設(shè)置差異
字符集
- TiDB 默認(rèn)：utf8mb4。
- MySQL 5.7 默認(rèn)：latin1。
- MySQL 8.0 默認(rèn)：utf8mb4。
排序規(guī)則
- TiDB 中 utf8mb4 字符集默認(rèn)：utf8mb4_bin。
- MySQL 5.7 中 utf8mb4 字符集默認(rèn)：utf8mb4_general_ci。
- MySQL 8.0 中 utf8mb4 字符集默認(rèn)：utf8mb4_0900_ai_ci。
大小寫敏感
關(guān)于lower_case_table_names的配置
- TiDB 默認(rèn)：2，且僅支持設(shè)置該值為 2。
- MySQL 默認(rèn)如下：
- Linux 系統(tǒng)中該值為 0
- Windows 系統(tǒng)中該值為 1
- macOS 系統(tǒng)中該值為 2
參數(shù)解釋
- lower_case_table_names=0 表名存儲(chǔ)為給定的大小和比較是區(qū)分大小寫的
- lower_case_table_names = 1 表名存儲(chǔ)在磁盤是小寫的，但是比較的時(shí)候是不區(qū)分大小寫
- lower_case_table_names=2 表名存儲(chǔ)為給定的大小寫但是比較的時(shí)候是小寫的
timestamp類型字段更新
默認(rèn)情況下，timestamp類型字段所在數(shù)據(jù)行被更新時(shí)，該字段會(huì)自動(dòng)更新為當(dāng)前時(shí)間，而參數(shù)explicit_defaults_for_timestamp控制這一種行為。
- TiDB 默認(rèn)：ON，且僅支持設(shè)置該值為 ON。
- MySQL 5.7 默認(rèn)：OFF。
- MySQL 8.0 默認(rèn)：ON。
參數(shù)解釋
- explicit_defaults_for_timestamp=off，數(shù)據(jù)行更新時(shí)，timestamp類型字段更新為當(dāng)前時(shí)間
- explicit_defaults_for_timestamp=on，數(shù)據(jù)行更新時(shí)，timestamp類型字段不更新為當(dāng)前時(shí)間。
外鍵支持
- TiDB 默認(rèn)：OFF，且僅支持設(shè)置該值為 OFF。
- MySQL 5.7 默認(rèn)：ON。
本文題目：別再分庫分表了，試試TiDB！
網(wǎng)頁網(wǎng)址：http://m.fisionsoft.com.cn/article/cdcpoej.html
