NewSQL 的應用：分佈式數據庫實踐篇 3

什麼是 NewSQL

NewSQL=RDBMS（ACID）+ SQL +NoSQL（擴展性）

所謂的 NewSQL 其實就是 在 NoSQL 上 改造，實現關係型數據。但是如果沒有 DB sharding 的需求，不要輕易上 NewSQL, 因爲那比較喫硬件資源。

NewSQL 主要目的是替換傳統 DB 的分庫分表，如 MySQL+MongoDB 的大數據性能瓶頸、業務層邏輯複雜度的增加（多維度 mapping）、運維成本（MySQK 5.5 不支持 online ddl）、故障切換時間長（30s-1 分鐘）、MHA/MMM 二次開發。

那麼，

NewSQL 目前有以下種類：

NewSQL 的數據隔離

快照隔離（snapshot isolation）是數據庫事務處理中的一個隔離級別，保證事務的讀操作將看到一個一致的數據庫的版本快照（實際上讀取比該事務早的最後一次提交值），寫操作成功提交的前提是沒有對該快照併發修改衝突。

很多重要的數據庫管理系統已經採用了快照隔離，如 InterBase, Firebird, Oracle, MySQL, PostgreSQL, SQL Anywhere（英語：Sql anywhere）, MongoDB 與 Microsoft SQL Server (從 2005)。原因是快照隔離比可順序化隔離級別的性能更好，且仍仍避免絕大多數併發異常。快照隔離一般用多版本併發控制 (MVCC) 實現。

TiDB 的架構

需要注意的是，TiDB 無法直接參與到分佈式事務中，它只是寫數據的時候可以強一致地寫到多個節點。也就是按照處理本地事務的方式來分佈式寫數據。

TiDB 高度兼容 MySQL 協議，基於 raft 算法的多副本複製。

TiDB 架構如下所示：

TiDB clutster 負責 SQL 語義解釋，TiKV 是真正存儲數據的地方，內部是 RocksDB。TiSpark 負責 OLAP 部分。TiKV 必須是 SSD 的，TiDB cluster 可是 SAS，但最好是 SSD。

TiDB 支持大多數 MySQL 語法，不支持存儲過程 / 自定義函數 / 觸發器。可實現基於 MySQL 業務無縫遷移。

通過對 TiDB 的壓力測試，得到如下結論：

TiDB 的預上線

線上業務的接入步驟：

測試（判斷 TiDB 業務場景滿足、性能）=> 同步數據 => 切流量

  1. 測試驗證：引流線上數據和流量到線下

  2. 大量功能和性能測試 (日誌、耗時；DBA 數據抽樣正確性驗證)

  3. TiDB 完全滿足消息業餘需求。

在同步數據時，TiDB 集羣作爲 MySQL 實例從庫，MySQL 單實例多個表同步到 TiDB 的一張大表。

切流量如上圖所示：

  1. 將讀流量灰度切換 TiDB，觀察一週，逐步灰度至 100%。

  2. 斷開 TiDB 與 MySQL 主從同步。

  3. 業務雙寫（確保業務隨時回滾到 MySQL）

  4. 業務停止 MySQL 寫入。

TiDB 的上線架構圖如下所示：

接下來，我們對比一下 TiDB 和 MySQL 的性能表現：

請求延時：

TiDB 整體相應延遲非常穩定，不受業務流量高峯影響。

MySQL 波動很大

TiDB/TiKV 通過無縫實例提升吞吐量。

業務請求隊列等到情況：

TiDB 恆爲 1

MySQL 抖動大

業務請求隊列等待情況：

接入 TiDB 後業務員服務接口耗時穩定無抖動，沒有發生丟棄的情況。

數據庫的無縫遷移

DB 無縫遷移的方式和數據的類型有有關：

時效性數據：紅包就是時效性數據

永久性數據：永久性數據如用戶數據

時效性數據遷移方案相對簡單：

接下來，我們看一個永久數據類型從 mongodb 遷移到 MySQL 的步驟。

mongodb 拿下來之前，一定會有一段時間雙寫：

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/xDVpLOowlRIOBowGrlODqg

猜你喜歡