以前研究過 NoSQL 中的 ElasticSearch，如果要直接從 SQL 跳到 NoSQL 確實存在一條大鴻溝，要將資料庫中的 Relational Table 轉換成 Big Table 觀念，有很多人還是無法接受，不敢相信巨大資料表可以跑得動，這就是 Scale Up 和 Scale Out 區別之所在。

當然 NoSQL 也存在一些缺點，不支援 SQL，也就是無法做 Join，這些以前資料庫管理系統做掉的事，現在需要程式員自行處理，也讓不少人打退堂鼓。NoSQL 也強調 NoSchema 的好處，反而成為程式員無法接受的地方。

還好有 NewSQL 出現，可以解決這些窘境，在 NewSQL 中，TiDB 表現亮眼，值得研究一番。TiDB 是 PingCAP 公司受 Google Spanner / F1 論文啟發而設計的開源分布式 HTAP (Hybrid Transactional and Analytical Processing) 資料庫，結合了傳統的 RDBMS 和 NoSQL 的最佳特性。

TiDB 兼容 MySQL，支持無限的水平擴展，具備強一致性和高可用性。TiDB 的目標是為 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 場景提供一站式的解決方案。

TiDB 的設計目標是 100% 的 OLTP 場景和 80% 的 OLAP 場景，更複雜的 OLAP 分析可以通過 TiSpark 項目來完成。TiDB 100% 支持標準的 ACID 事務。

TiDB 集群主要分為三個組件：

1. TiDB Server
TiDB Server 負責接收 SQL 請求，處理 SQL 相關的邏輯，並通過 PD 找到存儲計算所需數據的 TiKV 地址，與 TiKV 交互獲取數據，最終返回結果。 TiDB Server是無狀態的，其本身並不存儲數據，只負責計算，可以無限水平擴展，可以通過負載均衡組件（如LVS、HAProxy 或F5）對外提供統一的接入地址。

2. PD Server
Placement Driver (簡稱 PD) 是整個集群的管理模塊，其主要工作有三個： 一是存儲集群的元信息（某個 Key 存儲在哪個 TiKV 節點）；二是對 TiKV 集群進行調度和負載均衡（如數據的遷移、Raft group leader的遷移等）；三是分配全局唯一且遞增的事務 ID。PD 是一個集群，需要部署奇數個節點，一般線上推薦至少部署 3 個節點。

3. TiKV Server
TiKV Server 負責存儲數據，從外部看 TiKV 是一個分布式的提供事務的 Key-Value 存儲引擎。存儲數據的基本單位是 Region，每個 Region 負責存儲一個 Key Range （從 StartKey 到EndKey 的左閉右開區間）的數據，每個 TiKV 節點會負責多個 Region 。TiKV 使用 Raft協議做複製，保持數據的一致性和容災。副本以 Region 為單位進行管理，不同節點上的多個 Region 構成一個 RaftGroup，互為副本。數據在多個 TiKV 之間的負載均衡由 PD 調度，這裡也是以 Region 為單位進行調度。