TiFlash：並不是另外一個 T + 1 列存數據庫

在 上篇關於 TiFlash 的文章 發佈後，咱們收到了不少夥伴們的反饋，你們有各類各樣的疑問，包括 TiFlash 是否是 T + 1 列存數據庫？爲啥實時寫入也很快？讀壓力大怎麼辦？節點掛了怎麼辦？業務怎麼接入？……今天咱們就來詳細回覆一下你們的問題，但願能對你們理解和實踐 TiFlash 有所幫助。

並不是「另外一個 T + 1 列存數據庫」

首先，它並非獨立的列存數據庫：TiFlash 是配合 TiDB 體系的列存引擎，它和 TiDB 無縫結合，在線 DDL、無縫擴容、自動容錯等等方便運維的特色也在 TiFlash 中獲得繼承。

其次，TiFlash 能夠實時與行存保持同步。

T + 1 問題

「爲什麼要列和 MySQL 的對比呢？這樣是否太無聊？」

因爲 TiFlash 具有實時高頻實時更新能力，所以咱們在 上一篇 介紹中單機對單機比較了交易型數據庫例如 MySQL，由於這些特色通常是行存引擎具有的優點。TiFlash 與大多數列存不一樣的是，它支持實時更新，而且與行存數據保持同步。

「爲什麼說其餘列存數據庫沒法更新？我看到 XX 支持 Update 呀？」

多數列存引擎並非絕對不支持更新，而是不支持主鍵或惟一性約束，所以沒法像交易型數據庫那樣快速定位單條記錄並進行一致性更新，這也是你沒法向它們實時同步交易庫數據的緣由。針對這樣的設計，經常使用的更新方式是使用 ETL 去重和融合新老數據，而後批量導入列存，這就使得數據沒法實時分析而需等待數小時甚至一天。

TiFlash 是爲實時場景設計，所以咱們必須支持實時更新。在這個前提下，經過良好的設計和工程實現，也藉助 ClickHouse 極速的向量化引擎，TiFlash 仍然擁有不亞於甚至超出其餘列存引擎的優異性能。你們能夠參考 上一篇文章中的 Benchmark 。

爲何實時寫入也很快

「TiFlash 是列存，你們都說列存的實時寫入很慢，TiFlash 呢？」

通過業界驗證的實時更新列存方案是 Delta Main 設計。簡單說，就是將須要更新數據與整理好的不可變列存塊分開存放，讀時歸併，按期 Compact，而 TiFlash 也採起了相似設計思路。TiFlash 並不是是拍腦殼發明了一種可更新列存結構，而是參考了其餘成熟系統設計，如 Apache Kudu，CWI 的 Positional Delta Tree 等的設計思路，TiFlash 的設計也兼具了 B+ 樹和 LSM 的優點，在讀寫兩端都有優異的性能（但犧牲了對 TiFlash 場景無用的點查性能）。因爲無需考慮點查，所以 TiFlash 能夠以進行惰性數據整理加速寫入；因爲引入了讀時排序索引回寫，所以哪怕 Compact 不那麼頻繁仍能夠保持掃描高效，進一步減少寫放大加速寫入。

「TiFlash 進行 OLAP 讀取的時候會影響 OLTP 性能嗎？」

上篇文章 中已經展現過 TiFlash 的讀取性能：

注：爲了避免影響比例，上圖忽略了 MySQL 和 Oracle 數據。

下面帶你們看看更新寫入速度，這裏作了個簡單的寫入測試：

• 測試配置 3 節點 6 TiKV（3 副本）+ 2 節點 TiFlash（2 副本）。
• sysbench write-only 測試。
• 以 60954.39 的 QPS 進行混合寫入更新和刪除。
• 同時 TiFlash 不斷進行全表聚合計算。

測試結果是：

1. sysbench 運行 QPS 很是平穩，不會由於 AP 查詢而抖動。從上圖能夠看到，黃色線段表明 AP 查詢（開啓和關閉），開啓和關閉並不會對查詢產生抖動，哪怕 999 分位。
2. TiFlash 能夠很好匹配 TiKV 的實時寫入（包含增刪改而非僅僅插入）同時提供查詢。
3. 另外，咱們也觀測到，以大壓力寫入同時進行查詢，經過對 5000 個 TiFlash Region 副本採樣：讀取時，進行一致性校對 + 追趕 + 寫入的時間平均 27.31 毫秒，95分位在 73 毫秒，99分位是 609 毫秒，對於分析類查詢，這個延遲穩定性是能夠接受的。

實際上，在都只寫 1 副本的狀況下，TiFlash 的寫入性能大體能夠追上 2-3 個同規格 TiKV 節點，這確保了 TiFlash 在更少的資源配比下，也能夠匹配 TiKV 的寫入壓力。

爲什麼如此？

因爲 TiFlash 引擎針對 AP 場景無需點查的不一樣設計，它相對 LSM 引擎減少了寫放大比率：TiFlash 的寫放大大約在 3-7 倍之間。且在寫入約繁忙狀況下，因爲攢批效果反而越接近更小的三倍放大比率。而 LSM 結構下，RocksDB 的寫放大在 10 倍左右。這個對比優點大大提升了 TiFlash 磁盤實際能承載的業務吞吐量。

方便敏捷的運維

靈活擴容

「若是讀壓力也很大，你光寫得夠快有啥用啊？」

雖然咱們展現了 TiFlash 的寫入性能，其實哪怕它的寫入速度不如 TiKV，咱們仍然能夠單獨對 TiFlash 進行擴容。無論 TiFlash 的寫入性能多優秀，仍然有可能由於用戶的查詢讀取壓力過大而形成寫入速度降低，這時候是否就會產生嚴重的複製延遲呢？

會。可是 TiFlash 卻能夠依靠 TiDB 的體系單獨擴容，若是業務壓力過大，多上線幾臺 TiFlash 節點就能夠天然分擔數據和壓力，用戶徹底無需操心擴容過程，這些都是透明且自動的。相對於同節點的行列混合設計，這樣的架構無疑更靈活，且仍然保持了一致性。

自動恢復

「節點掛了怎麼辦？」

當 TiFlash 節點損壞下線，TiDB 體系能夠保證 TiFlash 的數據自動從行存恢復副本，而補副本的過程也會考慮不對 TiKV 產生衝擊。在 TiFlash 多副本的狀況下，這個過程對用戶也是徹底透明無感知的：你只須要將補充的服務器啓動上線就行。

無阻塞 DDL

「TiFlash 支持 DDL 嗎？」

TiFlash 繼承了 TiDB 體系的在線 DDL，尤爲是它支持了更改列類型。與傳統列存系統須要徹底重寫列格式不一樣，TiFlash 支持混合表結構，每一個列數據塊能夠有獨立的表結構，這使得 TiFlash 更改列類型是徹底實時且無負擔的：沒有數據須要被馬上重寫。這種設計，使得 TiFlash 能夠很容易被用於數據集成場合，任何上游數據源的表結構變動能夠無阻塞地被同步。

快速的業務接入

上述全部這些特性，使得 TiFlash 體系能夠很是便捷地承載實時分析業務。考慮一下若是你有一個新業務上線，你須要將在線業務接入分析平臺例如 Hadoop，你也許須要作以下事情：

1. 修改業務邏輯，在表結構中添加變動時間標記以便增量抽取。
2. 編寫定時任務，從源數據庫中抽取增量數據。
3. 將數據寫入 Staging 表，經過和 Hive 目標表進行 JOIN 並回寫以處理增量更新。
4. 極可能你還須要編寫數據校驗代碼按期檢查一致性。
5. 那麼也意味着你須要編寫不一致時的修復代碼。

這個過程可能須要耗費數天，甚至更久，而你還須要維護整個傳輸鏈路。

在 TiDB + TiFlash 體系下，你只須要一條命令：

ALTER TABLE your_table SET TIFLASH REPLICA 1;

你就能夠自動得到一份實時保持一致的列存數據鏡像，進行實時分析。

5秒（取決於你的手速） vs 數天

即使你已經有完整的 Hadoop 數倉建設，TiFlash 配合 TiSpark，也能夠輕鬆銜接兩個平臺的同時，爲離線數倉提供實時分析能力。

歡迎嚐鮮

TiFlash 已經在進行第一輪用戶測試，並在近期開啓第二批用戶測試，請關注後續信息，也歡迎聯繫詢問提早體驗 maxiaoyu@pingcap.com。來信請註明以下信息：姓名，公司，業務場景，是否已是 TiDB 用戶。