日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問(wèn)題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案
TIDB開(kāi)源分布式關(guān)系型數(shù)據(jù)庫(kù)

介紹

TiDB 是 PingCAP 公司自主設(shè)計(jì)、研發(fā)的開(kāi)源分布式關(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)景。

特點(diǎn)

  • 一鍵水平擴(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ù)派寫(xiě)入成功事務(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)化。
  • 兼容 MySQL 5.7 協(xié)議和 MySQL 生態(tài)：兼容 MySQL 5.7 協(xié)議、MySQL 常用的功能、MySQL 生態(tài)，應(yīng)用無(wú)需或者修改少量代碼即可從 MySQL 遷移到 TiDB。提供豐富的數(shù)據(jù)遷移工具幫助應(yīng)用便捷完成數(shù)據(jù)遷移。

與傳統(tǒng)的單機(jī)數(shù)據(jù)庫(kù)相比，TiDB 具有以下優(yōu)勢(shì)：

  • 純分布式架構(gòu)，擁有良好的擴(kuò)展性，支持彈性的擴(kuò)縮容。
  • 支持 SQL，對(duì)外暴露 MySQL 的網(wǎng)絡(luò)協(xié)議，并兼容大多數(shù) MySQL 的語(yǔ)法，在大多數(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)景。

場(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) 無(wú)法真實(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ù)無(wú)法滿足因數(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ì)越來(lái)越多，其規(guī)?？赡苓_(dá)到數(shù)百 TB 甚至 PB 級(jí)別，傳統(tǒng)的解決方案是通過(guò) OLTP 型數(shù)據(jù)庫(kù)處理在線聯(lián)機(jī)交易業(yè)務(wù)，通過(guò) ETL 工具將數(shù)據(jù)同步到 OLAP 型數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)分析，這種處理方案存在存儲(chǔ)成本高、實(shí)時(shí)性差等多方面的問(wèn)題。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)中，沒(méi)有一個(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)常見(jiàn)的解決方案是采用 ETL + Hadoop 來(lái)完成，但 Hadoop 體系太復(fù)雜，運(yùn)維、存儲(chǔ)成本太高無(wú)法滿足用戶的需求。與 Hadoop 相比，TiDB 就簡(jiǎn)單得多，業(yè)務(wù)通過(guò) ETL 工具或者 TiDB 的同步工具將數(shù)據(jù)同步到 TiDB，在 TiDB 中可通過(guò) SQL 直接生成報(bào)表。

架構(gòu)

在內(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 層本身是無(wú)狀態(tài)的，實(shí)踐中可以啟動(dòng)多個(gè) TiDB 實(shí)例，通過(guò)負(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 (Placement Driver) 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)，可以說(shuō)是整個(gè)集群的“大腦”。此外，PD 本身也是由至少 3 個(gè)節(jié)點(diǎn)構(gòu)成，擁有高可用的能力。建議部署奇數(shù)個(gè) PD 節(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 的左閉右開(kāi)區(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)景加速。

存儲(chǔ)

TiKV 沒(méi)有選擇直接向磁盤上寫(xiě)數(shù)據(jù)，而是把數(shù)據(jù)保存在 RocksDB 中，具體的數(shù)據(jù)落地由 RocksDB 負(fù)責(zé)。這個(gè)選擇的原因是開(kāi)發(fā)一個(gè)單機(jī)存儲(chǔ)引擎工作量很大，特別是要做一個(gè)高性能的單機(jī)引擎，需要做各種細(xì)致的優(yōu)化，而 RocksDB 是由 Facebook 開(kāi)源的一個(gè)非常優(yōu)秀的單機(jī) KV 存儲(chǔ)引擎，可以滿足 TiKV 對(duì)單機(jī)引擎的各種要求。這里可以簡(jiǎn)單的認(rèn)為 RocksDB 是一個(gè)單機(jī)的持久化 Key-Value Map。

TiKV 利用 Raft 來(lái)做數(shù)據(jù)復(fù)制，每個(gè)數(shù)據(jù)變更都會(huì)落地為一條 Raft 日志，通過(guò) Raft 的日志復(fù)制功能，將數(shù)據(jù)安全可靠地同步到復(fù)制組的每一個(gè)節(jié)點(diǎn)中。不過(guò)在實(shí)際寫(xiě)入中，根據(jù) Raft 的協(xié)議，只需要同步復(fù)制到多數(shù)節(jié)點(diǎn)，即可安全地認(rèn)為數(shù)據(jù)寫(xiě)入成功。

總結(jié)一下，通過(guò)單機(jī)的 RocksDB，TiKV 可以將數(shù)據(jù)快速地存儲(chǔ)在磁盤上；通過(guò) Raft，將數(shù)據(jù)復(fù)制到多臺(tái)機(jī)器上，以防單機(jī)失效。數(shù)據(jù)的寫(xiě)入是通過(guò) Raft 這一層的接口寫(xiě)入，而不是直接寫(xiě) RocksDB。通過(guò)實(shí)現(xiàn) Raft，TiKV 變成了一個(gè)分布式的 Key-Value 存儲(chǔ)，少數(shù)幾臺(tái)機(jī)器宕機(jī)也能通過(guò)原生的 Raft 協(xié)議自動(dòng)把副本補(bǔ)全，可以做到對(duì)業(yè)務(wù)無(wú)感知。

事務(wù)

TiDB 支持分布式事務(wù)，提供樂(lè)觀事務(wù)與悲觀事務(wù)兩種事務(wù)模式。TiDB 3.0.8 及以后版本，TiDB 默認(rèn)采用悲觀事務(wù)模式。TiDB 可以顯式地使用事務(wù)（通過(guò) [BEGIN|START TRANSACTION]/COMMIT 語(yǔ)句定義事務(wù)的開(kāi)始和結(jié)束）或者隱式地使用事務(wù) (SET autocommit = 1)。TiDB 支持語(yǔ)句執(zhí)行失敗后的原子性回滾。如果語(yǔ)句報(bào)錯(cuò)，則所做的修改將不會(huì)生效。該事務(wù)將保持打開(kāi)狀態(tài)，并且在發(fā)出 COMMIT 或 ROLLBACK 語(yǔ)句之前可以進(jìn)行其他修改。由于底層存儲(chǔ)引擎的限制，TiDB 要求單行不超過(guò) 6 MB。可以將一行的所有列根據(jù)類型轉(zhuǎn)換為字節(jié)數(shù)并加和來(lái)估算單行大小。

TiDB 同時(shí)支持樂(lè)觀事務(wù)與悲觀事務(wù)，其中樂(lè)觀事務(wù)是悲觀事務(wù)的基礎(chǔ)。由于樂(lè)觀事務(wù)是先將修改緩存在私有內(nèi)存中，因此，TiDB 對(duì)于單個(gè)事務(wù)的容量做了限制。

TiDB 中，單個(gè)事務(wù)的總大小默認(rèn)不超過(guò) 100 MB，這個(gè)默認(rèn)值可以通過(guò)配置文件中的配置項(xiàng) txn-total-size-limit 進(jìn)行修改，最大支持 10 GB。單個(gè)事務(wù)的實(shí)際大小限制還取決于服務(wù)器剩余可用內(nèi)存的大小，執(zhí)行事務(wù)時(shí) TiDB 進(jìn)程的內(nèi)存消耗相對(duì)于事務(wù)大小會(huì)存在一定程度的放大，最大可能達(dá)到提交事務(wù)大小的 6 倍以上。

在 4.0 以前的版本，TiDB 限制了單個(gè)事務(wù)的鍵值對(duì)的總數(shù)量不超過(guò) 30 萬(wàn)條，從 4.0 版本起 TiDB 取消了這項(xiàng)限制。

 兼容性

TiDB 高度兼容 MySQL 5.7 協(xié)議、MySQL 5.7 常用的功能及語(yǔ)法。MySQL 5.7 生態(tài)中的系統(tǒng)工具 (PHPMyAdmin、Navicat、MySQL Workbench、mysqldump、Mydumper/Myloader)、客戶端等均適用于 TiDB。但 TiDB 尚未支持一些 MySQL 功能，可能的原因如下：

  • 有更好的解決方案，例如 JSON 取代 XML 函數(shù)。
  • 目前對(duì)這些功能的需求度不高，例如存儲(chǔ)流程和函數(shù)。
  • 一些功能在分布式系統(tǒng)上的實(shí)現(xiàn)難度較大。

除此以外，TiDB 不支持 MySQL 復(fù)制協(xié)議，但提供了專用工具用于與 MySQL 復(fù)制數(shù)據(jù)。

  • 從 MySQL 復(fù)制：TiDB Data Migration (DM) 是將 MySQL/MariaDB 數(shù)據(jù)遷移到 TiDB 的工具，可用于增量數(shù)據(jù)的復(fù)制。
  • 向 MySQL 復(fù)制：TiCDC 是一款通過(guò)拉取 TiKV 變更日志實(shí)現(xiàn)的 TiDB 增量數(shù)據(jù)同步工具，可通過(guò) MySQL sink 將 TiDB 增量數(shù)據(jù)復(fù)制到 MySQL。

網(wǎng)站欄目：TIDB開(kāi)源分布式關(guān)系型數(shù)據(jù)庫(kù)
文章路徑：http://www.dlmjj.cn/article/djsisgi.html