來自： cnblogs.com/jiagooushi/p/17251486.html
即使是不懂編程的玩家，在對比 NAS 的時候，也會兩眼放光，考慮很多因素，比如 RAID 級別、速度、易用程度等。作為時時刻刻與程式碼打交道的我們，更需要關註數據的存取問題。
一開始，開箱即用的 MySQL，一定是企業的首選。不僅僅因為用的人多，更重要的是生態成熟。要工具有工具，要人有人。對於老板來說，員工看著不爽，可以隨時辭退，是一個非常理想的狀態。
但是，沒有胸懷的老板，幹的一定不會長久，因為如果商務會吹、老板會忽悠，業務會飛速發展（雖然現在這種機會比較少了）。對於 MySQL 來說，很快就會遇到問題。
MySQL 語法和 MySQL 協定，具有數據強一致的高可用特性，是一個不僅適合
OLTP
場景還適合 OLAP 場景的混合資料庫。
TiDB是 PingCAP公司自主設計、研發的開源分布式關系型資料庫，是一款同時支持線上事務處理與線上分析處理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分布式資料庫產品，具備水平擴容或者縮容、金融級高可用、即時 HTAP、雲原生的分布式資料庫、相容 MySQL 5.7 協定和 MySQL 生態等重要特性。
目標是為使用者提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解決方案。TiDB 適合高可用、強一致要求較高、數據規模較大等各種套用場景。
什麽是NewSQL
資料庫發展至今已經有3代了：
SQL，傳統關系型資料庫，例如 MySQL
noSQL，例如 MongoDB,Redis
newSQL
傳統SQL的問題
互聯網在本世紀初開始迅速發展，互聯網套用的使用者規模、數據量都越來越大，並且要求7X24小時線上。
傳統關系型資料庫在這種環境下成為了瓶頸，通常有2種解決方法：
升級伺服器硬體
雖然提升了效能，但總有天花板。
數據分片
使用分布式集群結構
對單點資料庫進行數據分片，存放到由廉價機器組成的分布式的集群裏，可延伸性更好了，但也帶來了新的麻煩。
以前在一個柯瑞的數據，現在跨了多個庫，套用系統不能自己去多個庫中操作，需要使用資料庫分片中介軟體。
分片中介軟體做簡單的數據操作時還好，但涉及到跨庫join、跨庫事務時就很頭疼了，很多人幹脆自己在業務層處理，復雜度較高。
NoSQL 的問題
後來 noSQL 出現了，放棄了傳統SQL的強事務保證和關系模型，重點放在資料庫的高可用性和可延伸性。
優點
高可用性和可延伸性，自動分區，輕松擴充套件
不保證強一致性，效能大幅提升
沒有關系模型的限制，極其靈活
缺點
不保證強一致性，對於普通套用沒問題，但還是有不少像金融一樣的企業級套用有強一致性的需求。
不支持 SQL 語句，相容性是個大問題，不同的 NoSQL 資料庫都有自己的 api 運算元據，比較復雜。
NewSQL 特性
NewSQL 提供了與 noSQL 相同的可延伸性，而且仍基於關系模型，還保留了極其成熟的 SQL 作為查詢語言，保證了ACID事務特性。
簡單來講，NewSQL 就是在傳統關系型資料庫上整合了 NoSQL 強大的可延伸性。
傳統的SQL架構設計基因中是沒有分布式的，而 NewSQL 生於雲時代，天生就是分布式架構。
NewSQL 的主要特性
SQL 支持，支持復雜查詢和大數據分析。
支持 ACID 事務，支持隔離級別。
彈性伸縮，擴容縮容對於業務層完全透明。
高可用，自動容災。
三種SQL的對比
TiDB怎麽來的
著名的開源分布式緩存服務 Codis 的作者， PingCAP 聯合創始人& CTO ，資深 infrastructure 工程師的黃東旭，擅長分布式儲存系統的設計與實作，開源狂熱分子的技術大神級別人物。即使在互聯網如此繁榮的今天，在資料庫這片邊界模糊且不確定地帶，他還在努力尋找確定性的實踐方向。
直到 2012 年底，他看到 Google 釋出的兩篇論文，如同棱鏡般，折射出他自己內心微爍的光彩。這兩篇論文描述了 Google 內部使用的一個海量關系型資料庫 F1/Spanner ，解決了關系型資料庫、彈性擴充套件以及全球分布的問題，並在生產中大規模使用。「如果這個能實作，對數據儲存領域來說將是顛覆性的」，黃東旭為完美方案的出現而興奮， PingCAP 的 TiDB 在此基礎上誕生了。
TiDB社群版和企業版
TiDB分為社群版以及企業版，企業版收費提供服務以及安全性的支持
TIDB 核心特性
水平彈性擴充套件
透過簡單地增加新節點即可實作 TiDB 的水平擴充套件，按需擴充套件吞吐或儲存，輕松應對高並行、海量數據場景
得益於 TiDB 儲存計算分離的架構的設計，可按需對計算、儲存分別進行線上擴容或者縮容，擴容或者縮容過程中對套用運維人員透明。
分布式事務支持
TiDB 100% 支持標準的 ACID 事務
金融級高可用
相比於傳統主從 (M-S) 復制方案，基於 Raft 的多數派選舉協定可以提供金融級的 100% 數據強一致性保證，且在不遺失大多數副本的前提下，可以實作故障的自動恢復 (auto-failover)，無需人工介入
數據采用多副本儲存，數據副本透過 Multi-Raft 協定同步事務日誌，多數派寫入成功事務才能送出，確保數據強一致性且少數副本發生故障時不影響數據的可用性。可按需配置副本地理位置、副本數量等策略滿足不同容災級別的要求。
即時 HTAP
TiDB 作為典型的 OLTP 行存資料庫，同時兼具強大的 OLAP 效能，配合 TiSpark ，可提供一站式 HTAP 解決方案，一份儲存同時處理 OLTP & OLAP 無需傳統繁瑣的 ETL 過程
提供行儲存引擎 TiKV、列儲存引擎 TiFlash 兩款儲存引擎，TiFlash 透過 Multi-Raft Learner 協定即時從 TiKV 復制數據，確保行儲存引擎 TiKV 和列儲存引擎 TiFlash 之間的數據強一致。TiKV、TiFlash 可按需部署在不同的機器，解決 HTAP 資源隔離的問題。
雲原生的分布式資料庫
TiDB 是為雲而設計的資料庫，同 Kubernetes 深度耦合，支持公有雲、私有雲和混合雲，使部署、配置和維護變得十分簡單。TiDB 的設計目標是 100% 的 OLTP 場景和 80% 的 OLAP 場景，更復雜的 OLAP 分析可以透過 TiSpark 計畫來完成。TiDB 對業務沒有任何侵入性，能優雅的替換傳統的資料庫中介軟體、資料庫分庫分表等 Sharding 方案。同時它也讓開發運維人員不用關註資料庫 Scale 的細節問題，專註於業務開發，極大的提升研發的生產力
高度相容 MySQL
相容 MySQL 5.7 協定、MySQL 常用的功能、MySQL 生態，套用無需或者修改少量程式碼即可從 MySQL 遷移到 TiDB。
提供豐富的數據遷移工具幫助套用便捷完成數據遷移，大多數情況下，無需修改程式碼即可從 MySQL 輕松遷移至 TiDB，分庫分表後的 MySQL 集群亦可透過 TiDB 工具進行即時遷移。
OLTP&OLAP(自學)
OLTP(線上事務處理)
OLTP(Online Transactional Processing) 即線上事務處理，OLTP 是傳統的關系型資料庫的主要套用，主要是基本的、日常的事務處理，記錄即時的增、刪、改、查，比如在銀行存取一筆款，就是一個事務交易
線上事務處理是事務性非常高的系統，一般都是高可用的線上系統，以小的事務以及小的查詢為主，評估其系統的時候，一般看其每秒執行的Transaction以及Execute SQL的數量。在這樣的系統中，單個資料庫每秒處理的Transaction往往超過幾百個，或者是幾千個，Select 語句的執行量每秒幾千甚至幾萬個。典型的OLTP系統有電子商務系統、銀行、證券等，如美國eBay的業務資料庫，就是很典型的OLTP資料庫。
OLAP(線上分析處理)
OLAP(Online Analytical Processing) 即線上分析處理，是資料倉儲的核心部心，支持復雜的分析操作，側重決策支持，並且提供直觀易懂的查詢結果。典型的套用就是復雜的動態報表系統
在這樣的系統中，語句的執行量不是考核標準，因為一條語句的執行時間可能會非常長，讀取的數據也非常多。所以，在這樣的系統中，考核的標準往往是磁盤子系統的吞吐量（頻寬），如能達到多少MB/s的流量。
特性對比
OLTP和OLAP的特性對比
—
OLTP
OLAP
即時性 | OLTP 即時性要求高，OLTP 資料庫旨在使事務應用程式僅寫入所需的數據，以便盡快處理單個事務 | OLAP 的即時性要求不是很高，很多套用頂多是每天更新一下數據 |
數據量 | OLTP 數據量不是很大，一般唯讀 / 寫數十條記錄，處理簡單的事務 | OLAP 數據量大，因為 OLAP 支持的是動態查詢，所以使用者也許要透過將很多數據的統計後才能得到想要知道的資訊，例如時間序列分析等等，所以處理的數據量很大 |
使用者和系統的面向性 | OLTP 是面向顧客的，用於事務和查詢處理 | OLAP 是面向市場的，用於數據分析 |
資料庫設計 | OLTP 采用實體 - 聯系 ER 模型和面向套用的資料庫設計 | OLAP 采用星型或雪花模型和面向主題的資料庫設計 |
設計角度區別
—
OLTP
OLAP
使用者 | 操作人員，低層管理人員 | 決策人員，高級管理人員 |
功能 | 日常操作處理 | 分析決策 |
主要工作 | 增、刪、改 | 查詢 |
DB 設計 | 面向套用 | 面向主題 |
數據 | 當前的，最新的細節，二維的，分立的 | 歷史的，聚集的，多維整合的，統一的 |
存取 | 讀/寫數十條記錄 | 讀上百萬條記錄 |
工作單位 | 簡單的事務 | 復雜的查詢 |
使用者數 | 上千個 | 上百個 |
DB 大小 | 100MB-GB | 100GB-TB |
TiDB 整體架構
TiDB的優勢
與傳統的單機資料庫相比，TiDB 具有以下優勢：
純分布式架構，擁有良好的擴充套件性，支持彈性的擴縮容
支持 SQL，對外暴露 MySQL 的網路協定，並相容大多數 MySQL 的語法，在大多數場景下可以直接替換 MySQL
預設支持高可用，在少數副本失效的情況下，資料庫本身能夠自動進行數據修復和故障轉移，對業務透明
支持 ACID 事務，對於一些有強一致需求的場景友好，例如：銀行轉賬
具有豐富的工具鏈生態，覆蓋數據遷移、同步、備份等多種場景
TiDB的元件
要深入了解 TiDB 的水平擴充套件和高可用特點，首先需要了解 TiDB 的整體架構。TiDB 集群主要包括三個核心元件：TiDB Server，PD Server 和 TiKV Server，此外，還有用於解決使用者復雜 OLAP 需求的 TiSpark 元件。
在內核設計上，TiDB 分布式資料庫將整體架構拆分成了多個模組，各模組之間互相通訊，組成完整的 TiDB 系統。對應的架構圖如下：
TiDB Server
TiDB Server 負責接收 SQL 請求，處理 SQL 相關的邏輯，並透過 PD 找到儲存計算所需數據的 TiKV 地址，與 TiKV 互動獲取數據，最終返回結果。TiDB Server 是無狀態的，其本身並不儲存數據，只負責計算，可以無限水平擴充套件，可以透過負載均衡元件（如 LVS、HAProxy 或 F5）對外提供統一的接入地址。
PD (Placement Driver) Server
Placement Driver (簡稱 PD) 是整個集群的管理模組，其主要工作有三個：
一是儲存集群的元資訊（某個 Key 儲存在哪個 TiKV 節點）；
二是對 TiKV 集群進行排程和負載均衡（如數據的遷移、Raft group leader 的遷移等）；
三是分配全域唯一且遞增的事務 ID。
PD 透過 Raft 協定保證數據的安全性。Raft 的 leader server 負責處理所有操作，其余的 PD server 僅用於保證高可用。建議部署奇數個 PD 節點
TiKV Server
TiKV Server 負責儲存數據，從外部看 TiKV 是一個分布式的提供事務的 Key-Value 儲存引擎。儲存數據的基本單位是 Region，每個 Region 負責儲存一個 Key Range（從 StartKey 到 EndKey 的左閉右開區間）的數據，每個 TiKV 節點會負責多個 Region。TiKV 使用 Raft 協定做復制，保持數據的一致性和容災。副本以 Region 為單位進行管理，不同節點上的多個 Region 構成一個 Raft Group，互為副本。數據在多個 TiKV 之間的負載均衡由 PD 排程，這裏也是以 Region 為單位進行排程。
TiSpark
TiSpark 作為 TiDB 中解決使用者復雜 OLAP 需求的主要元件，將 Spark SQL 直接執行在 TiDB 儲存層上，同時融合 TiKV 分布式集群的優勢，並融入大數據社群生態。至此，TiDB 可以透過一套系統，同時支持 OLTP 與 OLAP，免除使用者數據同步的煩惱。
TiFlash
TiFlash 是一類特殊的儲存節點。和普通 TiKV 節點不一樣的是，在 TiFlash 內部，數據是以列式的形式進行儲存，主要的功能是為分析型的場景加速。
TiKV整體架構
與傳統的整節點備份方式不同的，TiKV是將數據按照 key 的範圍劃分成大致相等的切片（下文統稱為 Region），每一個切片會有多個副本（通常是 3 個），其中一個副本是 Leader，提供讀寫服務。TiKV 透過 PD 對這些 Region 以及副本進行排程，以保證數據和讀寫負載都均勻地分散在各個 TiKV 上，這樣的設計保證了整個集群資源的充分利用並且可以隨著機器數量的增加水平擴充套件。
Region分裂與合並
當某個 Region 的大小超過一定限制（預設是 144MB）後，TiKV 會將它分裂為兩個或者更多個 Region，以保證各個 Region 的大小是大致接近的，這樣更有利於 PD 進行排程決策。同樣，當某個 Region 因為大量的刪除請求導致 Region 的大小變得更小時，TiKV 會將比較小的兩個相鄰 Region 合並為一個。
Region排程
Region 與副本之間透過 Raft 協定來維持數據一致性，任何寫請求都只能在 Leader 上寫入，並且需要寫入多數副本後（預設配置為 3 副本，即所有請求必須至少寫入兩個副本成功）才會返回客戶端寫入成功。
當 PD 需要把某個 Region 的一個副本從一個 TiKV 節點排程到另一個上面時，PD 會先為這個 Raft Group 在目標節點上增加一個 Learner 副本（復制 Leader 的數據）。當這個 Learner 副本的進度大致追上 Leader 副本時，Leader 會將它變更為 Follower，之後再移除操作節點的 Follower 副本，這樣就完成了 Region 副本的一次排程。
Leader 副本的排程原理也類似，不過需要在目標節點的 Learner 副本變為 Follower 副本後，再執行一次 Leader Transfer，讓該 Follower 主動發起一次選舉成為新 Leader，之後新 Leader 負責刪除舊 Leader 這個副本。
分布式事務
TiKV 支持分布式事務，使用者（或者 TiDB）可以一次性寫入多個 key-value 而不必關心這些 key-value 是否處於同一個數據切片 (Region) 上，TiKV 透過兩階段送出保證了這些讀寫請求的 ACID 約束。
高可用架構
高可用是 TiDB 的另一大特點，TiDB/TiKV/PD 這三個元件都能容忍部份例項失效，不影響整個集群的可用性。下面分別說明這三個元件的可用性、單個例項失效後的後果以及如何恢復。
TiDB高可用
TiDB 是無狀態的，推薦至少部署兩個例項，前端透過負載均衡元件對外提供服務。當單個例項失效時，會影響正在這個例項上進行的 Session，從套用的角度看，會出現單次請求失敗的情況，重新連線後即可繼續獲得服務。單個例項失效後，可以重新開機這個例項或者部署一個新的例項。
PD高可用
PD 是一個集群，透過 Raft 協定保持數據的一致性，單個例項失效時，如果這個例項不是 Raft 的 leader，那麽服務完全不受影響；如果這個例項是 Raft 的 leader，會重新選出新的 Raft leader，自動恢復服務。PD 在選舉的過程中無法對外提供服務，這個時間大約是3秒鐘。推薦至少部署三個 PD 例項，單個例項失效後，重新開機這個例項或者添加新的例項。
TiKV高可用
TiKV 是一個集群，透過 Raft 協定保持數據的一致性（副本數量可配置，預設保存三副本），並透過 PD 做負載均衡排程。單個節點失效時，會影響這個節點上儲存的所有 Region。對於 Region 中的 Leader 結點，會中斷服務，等待重新選舉；對於 Region 中的 Follower 節點，不會影響服務。當某個 TiKV 節點失效，並且在一段時間內（預設 10 分鐘）無法恢復，PD 會將其上的數據遷移到其他的 TiKV 節點上。
套用場景
MySQL分片與合並
TiDB 套用的第一類場景是 MySQL 的分片與合並。對於已經在用 MySQL 的業務，分庫、分表、分片、中介軟體是常用手段，隨著分片的增多，跨分片查詢是一大難題。TiDB 在業務層相容 MySQL 的存取協定，PingCAP 做了一個數據同步的工具——Syncer，它可以把黃東旭 TiDB 作為一個 MySQL Slave，將 TiDB 作為現有資料庫的從庫接在主 MySQL 庫的後方，在這一層將數據打通，可以直接進行復雜的跨庫、跨表、跨業務的即時 SQL 查詢。黃東旭提到，「過去的資料庫都是一主多從，有了 TiDB 以後，可以反過來做到內送流量備援容錯機制一從。」
直接替換MySQL
第二類場景是用 TiDB 直接去替換 MySQL。如果你的IT架構在搭建之初並未考慮分庫分表的問題，全部用了 MySQL，隨著業務的快速增長，海量高並行的 OLTP 場景越來越多，如何解決架構上的弊端呢?
在一個 TiDB 的資料庫上，所有業務場景不需要做分庫分表，所有的分布式工作都由資料庫層完成。TiDB 相容 MySQL 協定，所以可以直接替換 MySQL，而且基本做到了開箱即用，完全不用擔心傳統分庫分表方案帶來繁重的工作負擔和復雜的維護成本，友好的使用者介面讓常規的技術人員可以高效地進行維護和管理。另外，TiDB 具有 NoSQL 類似的擴容能力，在數據量和存取流量持續增長的情況下能夠透過水平擴容提高系統的業務支撐能力，並且響應延遲穩定。
資料倉儲
TiDB 本身是一個分布式系統，第三種使用場景是將 TiDB 當作資料倉儲使用。TPC-H 是數據分析領域的一個測試集，TiDB 2.0 在 OLAP 場景下的效能有了大幅提升，原來只能在資料倉儲裏面跑的一些復雜的 Query，在 TiDB 2.0 裏面跑，時間基本都能控制在 10 秒以內。當然，因為 OLAP 的範疇非常大，TiDB 的 SQL 也有搞不定的情況，為此 PingCAP 開源了 TiSpark，TiSpark 是一個 Spark 外掛程式，使用者可以直接用 Spark SQL 即時地在 TiKV 上做大數據分析。
作為其他系統的模組
TiDB 是一個傳統的儲存跟計算分離的計畫，其底層的 Key-Value 層，可以單獨作為一個 HBase 的 Replacement 來用，它同時支持跨行事務。TiDB 對外提供兩個 API 介面，一個是 ACID Transaction 的 API，用於支持跨行事務；另一個是 Raw API，它可以做單行的事務，換來的是整個效能的提升，但不提供跨行事務的 ACID 支持。使用者可以根據自身的需求在兩個 API 之間自行選擇。例如有一些使用者直接在 TiKV 之上實作了 Redis 協定，將 TiKV 替換一些大容量，對延遲要求不高的 Redis 場景。
套用案例
TiDB與MySQL相容性對比
TiDB 支持MySQL 傳輸協定及其絕大多數的語法。這意味著您現有的MySQL連結器和客戶端都可以繼續使用。大多數情況下您現有的套用都可以遷移至 TiDB，無需任何程式碼修改。
當前TiDB伺服器官方支持的版本為 MySQL 5.7 。大部份MySQL運維工具（如PHPMyAdmin, Navicat, MySQL Workbench等），以及備份恢復工具（如 mysqldump, Mydumper/myloader）等都可以直接使用。
不過一些特性由於在分布式環境下沒法很好的實作，目前暫時不支持或者是表現與MySQL有差異
一些MySQL語法在TiDB中可以解析透過，但是不會做任何後續的處理 ，例如Create Table語句中Engine，是解析並忽略。
TiDB不支持的MySql特性
儲存過程與函式
觸發器
事件
自訂函式
外來鍵約束
臨時表
全文/空間函式與索引
非
ascii
/
latin1
/
binary
/
utf8
/
utf8mb4
的字元集
SYS schema
MySQL 追蹤最佳化器
XML 函式
X-Protocol
Savepoints
列級許可權
XA
語法（TiDB 內部使用兩階段送出，但並沒有透過 SQL 介面公開）
CREATE TABLE tblName AS SELECT stmt
語法
CHECK TABLE
語法
CHECKSUM TABLE
語法
GET_LOCK
和
RELEASE_LOCK
函式
自增ID
TiDB 的自增列僅保證唯一，也能保證在單個 TiDB server 中自增，但不保證多個 TiDB server 中自增，不保證自動分配的值的連續性，建議不要將缺省值和自訂值混用，若混用可能會收
Duplicated Error
的錯誤資訊。
TiDB 可透過
tidb_allow_remove_auto_inc
系統變量開啟或者關閉允許移除列的
AUTO_INCREMENT
內容。刪除列內容的語法是：
alter table modify
或
alter table change
。
TiDB 不支持添加列的
AUTO_INCREMENT
內容，移除該內容後不可恢復。
SELECT 的限制
不支持
SELECT ... INTO @變量
語法。
不支持
SELECT ... GROUP BY ... WITH ROLLUP
語法。
TiDB 中的
SELECT .. GROUP BY expr
的返回結果與 MySQL 5.7 並不一致。MySQL 5.7 的結果等價於
GROUP BY expr ORDER BY expr
。而 TiDB 中該語法所返回的結果並不承諾任何順序，與 MySQL 8.0 的行為一致。
檢視
目前TiDB 不支持 對檢視進行UPDATE、INSERT、DELETE等 寫入操作 。
預設設定差異
字元集
TiDB 預設：
utf8mb4
。
MySQL 5.7 預設：
latin1
。
MySQL 8.0 預設：
utf8mb4
。
排序規則
TiDB 中
utf8mb4
字元集預設：
utf8mb4_bin
。
MySQL 5.7 中
utf8mb4
字元集預設：
utf8mb4_general_ci
。
MySQL 8.0 中
utf8mb4
字元集預設：
utf8mb4_0900_ai_ci
。
大小寫敏感
關於
lower_case_table_names
的配置
TiDB 預設：
2
，且僅支持設定該值為
2
。
MySQL 預設如下：
Linux 系統中該值為
0
Windows 系統中該值為
1
macOS 系統中該值為
2
參數解釋
lower_case_table_names=0 表名儲存為給定的大小和比較是區分大小寫的
lower_case_table_names = 1 表名儲存在磁盤是小寫的，但是比較的時候是不區分大小寫
lower_case_table_names=2 表名儲存為給定的大小寫但是比較的時候是小寫的
timestamp型別欄位更新
預設情況下，timestamp型別欄位所在數據行被更新時，該欄位會自動更新為當前時間，而參數explicit_defaults_for_timestamp控制這一種行為。
TiDB 預設：
ON
，且僅支持設定該值為
ON
。
MySQL 5.7 預設：
OFF
。
MySQL 8.0 預設：
ON
。
參數解釋
explicit_defaults_for_timestamp=off，數據行更新時，timestamp型別欄位更新為當前時間
explicit_defaults_for_timestamp=on，數據行更新時，timestamp型別欄位不更新為當前時間。
外來鍵支持
TiDB 預設：
OFF
，且僅支持設定該值為
OFF
。
MySQL 5.7 預設：
ON
。
