在 上篇關於 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 不斷進行全表聚合計算。
測試結果是：
-
sysbench 運行 QPS 非常平穩，不會因爲 AP 查詢而抖動。從上圖可以看到，黃色線段代表 AP 查詢（開啓和關閉），開啓和關閉並不會對查詢產生抖動，哪怕 999 分位。
-
TiFlash 可以很好匹配 TiKV 的實時寫入（包含增刪改而非僅僅插入）同時提供查詢。
-
另外，我們也觀測到，以大壓力寫入同時進行查詢，通過對 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，你也許需要做如下事情：
-
修改業務邏輯，在表結構中添加變更時間標記以便增量抽取。
-
編寫定時任務，從源數據庫中抽取增量數據。
-
將數據寫入 Staging 表，通過和 Hive 目標表進行 JOIN 並回寫以處理增量更新。
-
很可能你還需要編寫數據校驗代碼定期檢查一致性。
-
那麼也意味着你需要編寫不一致時的修復代碼。
這個過程可能需要耗費數天，甚至更久，而你還需要維護整個傳輸鏈路。
在 TiDB + TiFlash 體系下，你只需要一條命令：
ALTER TABLE your_table SET TIFLASH REPLICA 1;
你就可以自動獲得一份實時保持一致的列存數據鏡像，進行實時分析。
5秒（取決於你的手速） vs 數天
即便你已經有完整的 Hadoop 數倉建設，TiFlash 配合 TiSpark，也可以輕鬆銜接兩個平臺的同時，爲離線數倉提供實時分析能力。
歡迎嚐鮮
TiFlash 已經在進行第一輪用戶測試，並在近期開啓第二批用戶測試，請關注後續信息，也歡迎聯繫詢問提前體驗 [email protected]。來信請註明如下信息：姓名，公司，業務場景，是否已經是 TiDB 用戶。
