NewSQL

為什麼出現 NewSQL#

過去 20 年資料庫的演進路線：

RDBMS (1970s-)
   ↓ 不夠擴展
NoSQL (2000s-)：MongoDB、Cassandra、DynamoDB
   ↓ 為了擴展犧牲了 SQL、事務、一致性
NewSQL (2010s-)：CockroachDB、TiDB、Spanner、YugabyteDB
   ↓ 試圖找回 SQL + ACID + 分散式擴展

NewSQL 的願景：寫起來像單機 MySQL，跑起來像分散式系統。

為什麼 NoSQL 不夠#

NoSQL 解決「擴展性」很成功，但代價：

無 SQL（要學 API）
無強事務（最多單分片）
無 join（應用層自己組）
一致性弱（最終）
應用程式碼複雜化

對電商核心交易（訂單、賬戶），這些都是 dealbreaker。

NewSQL 的代表#

系統	出身	特色
Spanner	Google 內部	全球強一致、TrueTime
F1	Google，建於 Spanner 之上	Google 廣告系統
CockroachDB	前 Google Spanner 工程師	Spanner 開源實作
TiDB	PingCAP（中國）	MySQL 協議相容
YugabyteDB	前 Facebook	PostgreSQL 協議相容
OceanBase	阿里	雙模引擎 OLTP + OLAP
TiDB Cloud / Cockroach Cloud	商業 SaaS	雲端託管

底層都是 Raft + sharding + distributed SQL 的組合，差別在執行細節。

CockroachDB / Spanner 風格架構#

                  Client
                    │ SQL
                    ▼
              +-----------+
              |  SQL Layer|  parse、optimize、planning
              +-----+-----+
                    │
                    ▼
              +-----------+
              | Distributed| 跨 range 協調、txn coordinator
              | Txn Layer |
              +-----+-----+
                    │
                    ▼
        +----------+----------+
        |   KV Layer (Range)  |
        |   - Range = key 區間  |
        |   - 每 Range 跨 3 副本 |
        +----------+----------+
                    │
                    ▼
              +-----------+
              | RocksDB   |  每副本本地 LSM-Tree 存
              +-----------+

關鍵概念：

Range / Region#

連續 key 範圍構成一個 Range（CockroachDB 預設 ~512 MB / range，TiDB 預設 96 MB / region）：

table orders 的 PK 範圍
├─ Range 1：[orders/1 ... orders/1000)
├─ Range 2：[orders/1000 ... orders/2000)
├─ Range 3：[orders/2000 ... orders/3000)
└─ ...

每個 Range 自動被複製到 3 個節點，用 Raft 達成共識。

Raft#

Raft 是 Paxos 的可理解版本：

Leader（每 range 一個）─→ Followers
   │
   │ append log entry
   │ wait for majority ack
   │ commit
   ▼
   Apply

寫入需要 majority（3 副本中的 2）ack 才算成功。一個節點掛 → 仍能寫；兩個節點掛 → 該 range 寫入暫停。

自動分裂與遷移#

Range 大小到達閾值 → 自動 split 成兩個。某節點 hot → 自動 rebalance：把部分 range 的 leader 或副本搬走。

「自動」是 NewSQL 與 MySQL 分片的核心差別 ── 業務不需要手動管 sharding。

分散式事務：2PC + 時間戳#

跨多個 range 的事務怎麼保證 ACID？

CockroachDB 用「Multi-version + 2PC」：

Begin txn → 取一個 timestamp T
所有讀 / 寫都在 T 時間版本
Commit phase:
  1. Prepare：在所有涉及的 range 寫 intent
  2. Commit：標記 intent 為已提交
  3. 並發讀者看到 intent 會等

這比傳統 2PC 強的關鍵：用時間戳 + MVCC 提供「不阻塞讀」的能力。讀者讀 T - ε 的版本，永不需要等待寫。

TrueTime：Google 的祕密武器#

Spanner 用全球同步的物理時鐘 + 不確定性區間 [t-ε, t+ε]：

每筆事務取到一個 commit timestamp
ε 內等待保證跨 region 順序

CockroachDB 沒有 TrueTime（沒有 GPS + atomic clock），改用 HLC（Hybrid Logical Clock）+ uncertainty 處理。在多 region 場景下，CRDB 會在某些情況需要 retry，Spanner 不需要。

SQL 與 join#

NewSQL 支援完整 SQL：JOIN、subquery、window functions、CTE。

SELECT u.name, COUNT(o.id) AS order_count
FROM users u JOIN orders o ON u.id = o.user_id
WHERE o.created_at > '2025-01-01'
GROUP BY u.name
ORDER BY order_count DESC
LIMIT 10;

優化器自動分散式執行：

並行掃多個 range
在資料所在地計算（謂詞下推）
跨 range join 用 hash join 或 streaming

但 join 性能仍不及單機 ── 跨 range join 需要 shuffle，慢於同機 join。

TiDB 的 MySQL 協議相容#

TiDB 接 MySQL 協議：

MySQL Client → TiDB（看起來像 MySQL）→ 內部分散式

任何 MySQL 用戶端、ORM、工具都能用，業務代碼幾乎不改。這是 TiDB 在中文社群快速普及的關鍵。

YugabyteDB 同樣對接 PostgreSQL 協議。

性能特性與限制#

NewSQL 與 MySQL 對比：

維度	MySQL（單庫）	NewSQL
寫延遲	1~5 ms	5~20 ms（Raft consensus）
讀延遲	1 ms	1~10 ms（route + range）
寫吞吐	數萬 QPS	線性擴展
容量	TB	PB
強事務	是	是
跨表事務	是	是
線性擴容	否（要分片）	是
故障切換	半自動	自動
複雜度	低	高
成本	低	較高

NewSQL 不是免費午餐：

寫延遲較高（共識）
大事務性能差
全表掃描可能慢
運維比 MySQL 複雜（很多新概念）
對網路品質敏感

適合與不適合#

適合#

資料量已是分庫分表級別（10TB+）
跨片強事務需求
線性擴容要求
願意花時間學新系統
有 DevOps / SRE 能力

不適合#

小資料量（< 1TB）── MySQL 完全夠
極端低延遲（< 1ms 寫）
大量短小寫入混合大事務
團隊沒有相關經驗
依賴某些 MySQL 特性（如 GTID 跨 region 同步）

一個成功故事：Shopify#

Shopify 從 MySQL 分片走向 Vitess（仍是 MySQL 變體，但能水平擴展）。再進一步觀察 TiDB / CockroachDB 用於某些子系統。

關鍵教訓：

分庫分表撐了多年是 ROI 高的選擇
真正分散式 SQL 在資料量極大時才必要
一步到位選 NewSQL ≠ 對的決策；演進過程要看業務階段

與雲端的整合#

雲端 NewSQL 託管服務：

TiDB Cloud：PingCAP 託管
CockroachDB Cloud / Serverless：Cockroach Labs 託管
AlloyDB：Google 仿 Aurora 的 PG
Aurora：AWS 的 MySQL/PG，不是真 NewSQL 但分離儲存與計算

雲端託管把運維複雜度極大降低 ── 對中型公司，「直接用雲」可能比自建任何分散式 DB 都務實。

與 OLAP 的融合：HTAP#

TiDB 推 HTAP（Hybrid Transactional / Analytical Processing）：

TiKV（行存，OLTP）── Raft sync ──→ TiFlash（列存，OLAP）

同一份資料兩種儲存，OLTP 在 TiKV、OLAP 即時打 TiFlash。少了一條 ETL pipeline。

這是 NewSQL 的下一步：「一個系統解決所有」。但實作極困難，目前 HTAP 多用於中規模分析需求。超大規模 OLAP 仍走專用 ClickHouse / Snowflake。

是 MySQL 的繼任者嗎#

短期不會。原因：

MySQL 太成熟、社群太大
多數公司資料量 < 5 TB，分片夠了
NewSQL 的複雜度對運維是真實負擔

但 NewSQL 在這些場景成為標配：

雲廠商主推（AWS、GCP、阿里）
國內互聯網大廠（Bytedance、美團、Shopee）
超大規模 SaaS

未來 5 年趨勢：MySQL/PostgreSQL 仍是大多數預設，NewSQL 在「需要無痛擴容」場景吞下市場。

小結#

NewSQL = 分散式 SQL + ACID + 自動分片
核心：Raft 複製 + Range/Region 自動分裂 + 分散式事務（時間戳 + 2PC）
代表：Spanner / CockroachDB / TiDB / YugabyteDB / OceanBase
適合：資料量極大 + 需要強一致 + 願意投入學習
不適合：小資料量 + 極端低延遲 + 團隊新手
託管雲服務大幅降低使用門檻

下章看 NewSQL 與許多現代儲存的底層 ── RocksDB 與 LSM-Tree。