1鉴分、背景
傳統(tǒng)的數(shù)據(jù)庫(kù)單表超過千萬級(jí)別性能會(huì)急劇下降哮幢,不滿足某些行業(yè)的業(yè)務(wù)需求(電商之類數(shù)據(jù)量巨大的)。
那么怎么解決這種大數(shù)據(jù)量的存儲(chǔ)呢志珍,大體有2種方式:1橙垢、使用分布式存儲(chǔ)來解決這個(gè)問題(nosql,大數(shù)據(jù)hadoop的hdfs)伦糯;2柜某、數(shù)據(jù)庫(kù)分庫(kù)分表。
NoSQL敛纲,泛指非關(guān)系型的數(shù)據(jù)庫(kù)喂击,具體分類如下:
數(shù)據(jù)庫(kù)分庫(kù)分表有不少成熟的框架,具體如下:
其中用得比較多的應(yīng)該是MyCAT(需要服務(wù)端)淤翔,官網(wǎng)地址http://www.mycat.org.cn/翰绊。
還有以前當(dāng)當(dāng)?shù)膕hardingjdbc(不需要服務(wù)端),現(xiàn)在改名成shardingsphere(也有支持服務(wù)端的sharding-proxy)旁壮,官網(wǎng)地址http://shardingsphere.apache.org/监嗜。
其中nosql的方案不支持?jǐn)?shù)據(jù)庫(kù)的ACID,只能保證最終一致性抡谐;
分庫(kù)分表可以解決問題裁奇,但是會(huì)引進(jìn)不少其他的問題需要解決,而且對(duì)運(yùn)維的難度有所提升麦撵;這里有一篇介紹分庫(kù)分表方案的不足的帖子https://dbaplus.cn/news-11-1854-1.html
2刽肠、TiDB簡(jiǎn)介
在各種解決方案都不是非常好的情況下,誕生了一種新的數(shù)據(jù)庫(kù)newsql:NewSQL 是對(duì)各種新的可擴(kuò)展/高性能數(shù)據(jù)庫(kù)的簡(jiǎn)稱厦坛,這類數(shù)據(jù)庫(kù)不僅具有NoSQL對(duì)海量數(shù)據(jù)的存儲(chǔ)管理能力五垮,還保持了傳統(tǒng)數(shù)據(jù)庫(kù)支持ACID和SQL等特性乍惊。
這里有一篇關(guān)于newsql的帖子可以了解下:https://cloud.tencent.com/developer/article/1445846
其中TiDB是用go開發(fā)的一款newsql杜秸,官網(wǎng)地址是https://pingcap.com/。git地址https://github.com/pingcap
TiDB 是 PingCAP 公司自主設(shè)計(jì)润绎、研發(fā)的開源分布式關(guān)系型數(shù)據(jù)庫(kù)撬碟,是一款同時(shí)支持在線事務(wù)處理與在線分析處理 (Hybrid Transactional and Analytical Processing, HTAP)的融合型分布式數(shù)據(jù)庫(kù)產(chǎn)品,具備水平擴(kuò)容或者縮容莉撇、金融級(jí)高可用呢蛤、實(shí)時(shí) HTAP、云原生的分布式數(shù)據(jù)庫(kù)棍郎、兼容 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)用場(chǎng)景汽抚。
2.1抓狭、TiDB 整體架構(gòu)
與傳統(tǒng)的單機(jī)數(shù)據(jù)庫(kù)相比,TiDB 具有以下優(yōu)勢(shì):
- 純分布式架構(gòu)造烁,擁有良好的擴(kuò)展性否过,支持彈性的擴(kuò)縮容
- 支持 SQL,對(duì)外暴露 MySQL 的網(wǎng)絡(luò)協(xié)議惭蟋,并兼容大多數(shù) MySQL 的語法苗桂,在大多數(shù)場(chǎng)景下可以直接替換 MySQL
- 默認(rèn)支持高可用,在少數(shù)副本失效的情況下敞葛,數(shù)據(jù)庫(kù)本身能夠自動(dòng)進(jìn)行數(shù)據(jù)修復(fù)和故障轉(zhuǎn)移誉察,對(duì)業(yè)務(wù)透明
- 支持 ACID 事務(wù),對(duì)于一些有強(qiáng)一致需求的場(chǎng)景友好惹谐,例如:銀行轉(zhuǎn)賬
- 具有豐富的工具鏈生態(tài)持偏,覆蓋數(shù)據(jù)遷移、同步氨肌、備份等多種場(chǎng)景
在內(nèi)核設(shè)計(jì)上鸿秆,TiDB 分布式數(shù)據(jù)庫(kù)將整體架構(gòu)拆分成了多個(gè)模塊,各模塊之間互相通信怎囚,組成完整的 TiDB 系統(tǒng)卿叽。對(duì)應(yīng)的架構(gòu)圖如下:
TiDB Server:SQL 層,對(duì)外暴露 MySQL 協(xié)議的連接 endpoint恳守,負(fù)責(zé)接受客戶端的連接考婴,執(zhí)行 SQL 解析和優(yōu)化,最終生成分布式執(zhí)行計(jì)劃催烘。TiDB 層本身是無狀態(tài)的沥阱,實(shí)踐中可以啟動(dòng)多個(gè) TiDB 實(shí)例,通過負(fù)載均衡組件(如 LVS伊群、HAProxy 或 F5)對(duì)外提供統(tǒng)一的接入地址考杉,客戶端的連接可以均勻地分?jǐn)傇诙鄠€(gè) TiDB 實(shí)例上以達(dá)到負(fù)載均衡的效果。TiDB Server 本身并不存儲(chǔ)數(shù)據(jù)舰始,只是解析 SQL崇棠,將實(shí)際的數(shù)據(jù)讀取請(qǐng)求轉(zhuǎn)發(fā)給底層的存儲(chǔ)節(jié)點(diǎn) TiKV(或 TiFlash)。
PD Server:整個(gè) TiDB 集群的元信息管理模塊丸卷,負(fù)責(zé)存儲(chǔ)每個(gè) TiKV 節(jié)點(diǎn)實(shí)時(shí)的數(shù)據(jù)分布情況和集群的整體拓?fù)浣Y(jié)構(gòu)枕稀,提供 TiDB Dashboard 管控界面,并為分布式事務(wù)分配事務(wù) ID。PD 不僅存儲(chǔ)元信息萎坷,同時(shí)還會(huì)根據(jù) TiKV 節(jié)點(diǎn)實(shí)時(shí)上報(bào)的數(shù)據(jù)分布狀態(tài)范抓,下發(fā)數(shù)據(jù)調(diào)度命令給具體的 TiKV 節(jié)點(diǎn),可以說是整個(gè)集群的“大腦”食铐。此外匕垫,PD 本身也是由至少 3 個(gè)節(jié)點(diǎn)構(gòu)成,擁有高可用的能力虐呻。建議部署奇數(shù)個(gè) PD 節(jié)點(diǎn)象泵。
-
存儲(chǔ)節(jié)點(diǎn)
- 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 的 API 在 KV 鍵值對(duì)層面提供對(duì)分布式事務(wù)的原生支持忽孽,默認(rèn)提供了 SI (Snapshot Isolation) 的隔離級(jí)別,這也是 TiDB 在 SQL 層面支持分布式事務(wù)的核心谢床。TiDB 的 SQL 層做完 SQL 解析后兄一,會(huì)將 SQL 的執(zhí)行計(jì)劃轉(zhuǎn)換為對(duì) TiKV API 的實(shí)際調(diào)用。所以识腿,數(shù)據(jù)都存儲(chǔ)在 TiKV 中出革。另外,TiKV 中的數(shù)據(jù)都會(huì)自動(dòng)維護(hù)多副本(默認(rèn)為三副本)渡讼,天然支持高可用和自動(dòng)故障轉(zhuǎn)移骂束。
- TiFlash:TiFlash 是一類特殊的存儲(chǔ)節(jié)點(diǎn)。和普通 TiKV 節(jié)點(diǎn)不一樣的是成箫,在 TiFlash 內(nèi)部展箱,數(shù)據(jù)是以列式的形式進(jìn)行存儲(chǔ),主要的功能是為分析型的場(chǎng)景加速蹬昌。
2.2混驰、與 MySQL 兼容性對(duì)比概覽
基本上mysql的基本功能都支持:
- TiDB 100% 兼容 MySQL 5.7 協(xié)議、MySQL 5.7 常用的功能及語法凳厢。MySQL 5.7 生態(tài)中的系統(tǒng)工具(PHPMyAdmin账胧、Navicat竞慢、MySQL Workbench先紫、mysqldump、Mydumper/Myloader)筹煮、客戶端等均用于 TiDB遮精。
- 由于 TiDB 是一款分布式數(shù)據(jù)庫(kù),MySQL 5.7 中的部分特性因工程實(shí)現(xiàn)難度較大,投入產(chǎn)出比較低等多種原因在 TiDB 中未能實(shí)現(xiàn)或者僅兼容語法但功能并沒有實(shí)現(xiàn)本冲,因此使用過程中請(qǐng)?zhí)貏e注意准脂。例如:
CREATE TABLE
語句中ENGINE
,僅兼容語法檬洞,功能并沒有實(shí)現(xiàn)狸膏,因此 TiDB 中沒有ENGINE
這類的概念。
不支持的功能特性:
- 存儲(chǔ)過程與函數(shù)
- 觸發(fā)器
- 事件
- 自定義函數(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
語法 -
CREATE TEMPORARY TABLE
語法 -
CHECK TABLE
語法 -
CHECKSUM TABLE
語法
更詳細(xì)的內(nèi)容查看官網(wǎng):https://docs.pingcap.com/zh/tidb/stable/mysql-compatibility
2.3湾戳、TiDB 軟件和硬件環(huán)境建議配置
TiDB對(duì)于硬件的要求不是很低,存儲(chǔ)的TiKv和TiFlash都需要固態(tài)硬盤广料,尤其是用于分析的TiFlash內(nèi)存和cpu要求比較高(這里暫時(shí)就不介紹怎么安裝了):
其他配置詳見:https://pingcap.com/docs-cn/stable/hardware-and-software-requirements/
2.4砾脑、適用場(chǎng)景
- 對(duì)數(shù)據(jù)一致性及高可靠、系統(tǒng)高可用艾杏、可擴(kuò)展性韧衣、容災(zāi)要求較高的金融行業(yè)屬性的場(chǎng)景
眾所周知,金融行業(yè)對(duì)數(shù)據(jù)一致性及高可靠购桑、系統(tǒng)高可用畅铭、可擴(kuò)展性、容災(zāi)要求較高勃蜘。傳統(tǒng)的解決方案是同城兩個(gè)機(jī)房提供服務(wù)顶瞒、異地一個(gè)機(jī)房提供數(shù)據(jù)容災(zāi)能力但不提供服務(wù),此解決方案存在以下缺點(diǎn):資源利用率低元旬、維護(hù)成本高榴徐、RTO (Recovery Time Objective) 及 RPO (Recovery Point Objective) 無法真實(shí)達(dá)到企業(yè)所期望的值。TiDB 采用多副本 + Multi-Raft 協(xié)議的方式將數(shù)據(jù)調(diào)度到不同的機(jī)房匀归、機(jī)架坑资、機(jī)器,當(dāng)部分機(jī)器出現(xiàn)故障時(shí)系統(tǒng)可自動(dòng)進(jìn)行切換穆端,確保系統(tǒng)的 RTO <= 30s 及 RPO = 0 袱贮。 - 對(duì)存儲(chǔ)容量、可擴(kuò)展性体啰、并發(fā)要求較高的海量數(shù)據(jù)及高并發(fā)的 OLTP 場(chǎng)景
隨著業(yè)務(wù)的高速發(fā)展攒巍,數(shù)據(jù)呈現(xiàn)爆炸性的增長(zhǎng),傳統(tǒng)的單機(jī)數(shù)據(jù)庫(kù)無法滿足因數(shù)據(jù)爆炸性的增長(zhǎng)對(duì)數(shù)據(jù)庫(kù)的容量要求荒勇,可行方案是采用分庫(kù)分表的中間件產(chǎn)品或者 NewSQL 數(shù)據(jù)庫(kù)替代柒莉、采用高端的存儲(chǔ)設(shè)備等,其中性價(jià)比最大的是 NewSQL 數(shù)據(jù)庫(kù)沽翔,例如:TiDB兢孝。TiDB 采用計(jì)算窿凤、存儲(chǔ)分離的架構(gòu),可對(duì)計(jì)算跨蟹、存儲(chǔ)分別進(jìn)行擴(kuò)容和縮容雳殊,計(jì)算最大支持 512 節(jié)點(diǎn),每個(gè)節(jié)點(diǎn)最大支持 1000 并發(fā)窗轩,集群容量最大支持 PB 級(jí)別夯秃。 - Real-time HTAP 場(chǎng)景
隨著 5G、物聯(lián)網(wǎng)痢艺、人工智能的高速發(fā)展寝并,企業(yè)所生產(chǎn)的數(shù)據(jù)會(huì)越來越多,其規(guī)母贡福可能達(dá)到數(shù)百 TB 甚至 PB 級(jí)別衬潦,傳統(tǒng)的解決方案是通過 OLTP 型數(shù)據(jù)庫(kù)處理在線聯(lián)機(jī)交易業(yè)務(wù),通過 ETL 工具將數(shù)據(jù)同步到 OLAP 型數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)分析植酥,這種處理方案存在存儲(chǔ)成本高镀岛、實(shí)時(shí)性差等多方面的問題。TiDB 在 4.0 版本中引入列存儲(chǔ)引擎 TiFlash 結(jié)合行存儲(chǔ)引擎 TiKV 構(gòu)建真正的 HTAP 數(shù)據(jù)庫(kù)友驮,在增加少量存儲(chǔ)成本的情況下漂羊,可以同一個(gè)系統(tǒng)中做聯(lián)機(jī)交易處理、實(shí)時(shí)數(shù)據(jù)分析卸留,極大地節(jié)省企業(yè)的成本走越。 - 數(shù)據(jù)匯聚、二次加工處理的場(chǎng)景
當(dāng)前絕大部分企業(yè)的業(yè)務(wù)數(shù)據(jù)都分散在不同的系統(tǒng)中耻瑟,沒有一個(gè)統(tǒng)一的匯總旨指,隨著業(yè)務(wù)的發(fā)展,企業(yè)的決策層需要了解整個(gè)公司的業(yè)務(wù)狀況以便及時(shí)做出決策喳整,故需要將分散在各個(gè)系統(tǒng)的數(shù)據(jù)匯聚在同一個(gè)系統(tǒng)并進(jìn)行二次加工處理生成 T+0 或 T+1 的報(bào)表谆构。傳統(tǒng)常見的解決方案是采用 ETL + Hadoop 來完成,但 Hadoop 體系太復(fù)雜框都,運(yùn)維搬素、存儲(chǔ)成本太高無法滿足用戶的需求。與 Hadoop 相比魏保,TiDB 就簡(jiǎn)單得多熬尺,業(yè)務(wù)通過 ETL 工具或者 TiDB 的同步工具將數(shù)據(jù)同步到 TiDB,在 TiDB 中可通過 SQL 直接生成報(bào)表谓罗。
最后粱哼,一些合作案例和PingCAP公司相關(guān)的文章地址http://www.ctoutiao.com/c/74735854/