TiDB目前即將發(fā)布RC3版本，預計六月份能夠發(fā)布GA版本。在即將到來的 RC3版本中，對MySQL兼容性、SQL優(yōu)化器、系統(tǒng)穩(wěn)定性、性能做了大量的工作。對于OLTP場景，重點優(yōu)化寫入性能。另外提供了權限管理功能，用戶可以按照MySQL的權限管理方式控制數(shù)據訪問權限。對于OLAP場景，也對優(yōu)化器做了大量的工作，包括更多語句的優(yōu)化、支持SortMergeJoin算子、IndexLookupJoin算子。另外對內存使用也做了大量的優(yōu)化，一些場景下，內存使用下降75%。
除了TiDB本身的優(yōu)化之外，我們還在做一個新的工程，名字叫TiSpark。簡單來講，就是讓Spark更好地接入TiDB。現(xiàn)在其實Spark已經可以通過JDBC接口讀取TiDB中的數(shù)據，但是這里有兩個問題：1. 只能通過單個TiDB節(jié)點讀取數(shù)據且數(shù)據需要從TiKV中經過 TiDB 中轉。2. 不能和Spark的優(yōu)化器相結合，我們期望能和Spark的優(yōu)化器整合，將Filter、聚合能通過TiKV的分布式計算能力提速。這個項目已經開始開發(fā)，預計近期開源，五月份就能有第一個版本。
三、分布式數(shù)據庫的未來趨勢
關于未來，我覺得未來的數(shù)據庫會有幾個趨勢，也是TiDB項目追求的目標：
1、數(shù)據庫會隨著業(yè)務云化，未來一切的業(yè)務都會跑在云端，不管是私有云或者公有云，運維團隊接觸的可能再也不是真實的物理機，而是一個個隔離的容器或者「計算資源」，這對數(shù)據庫也是一個挑戰(zhàn)，因為數(shù)據庫天生就是有狀態(tài)的，數(shù)據總是要存儲在物理的磁盤上，而數(shù)據移動的代價比移動容器的代價可能大很多。
2、多租戶技術會成為標配，一個大數(shù)據庫承載一切的業(yè)務，數(shù)據在底層打通，上層通過權限，容器等技術進行隔離，但是數(shù)據的打通和擴展會變得異常簡單，結合第一點提到的云化，業(yè)務層可以再也不用關心物理機的容量和拓撲，只需要認為底層是一個無窮大的數(shù)據庫平臺即可，不用再擔心單機容量和負載均衡等問題。
3、OLAP和OLTP業(yè)務會融合，用戶將數(shù)據存儲進去后，需要比較方便高效的方式訪問這塊數(shù)據，但是OLTP和OLAP在SQL優(yōu)化器/執(zhí)行器這層的實現(xiàn)一定是千差萬別的。以往的實現(xiàn)中，用戶往往是通過ETL工具將數(shù)據從OLTP數(shù)據庫同步到OLAP數(shù)據庫，這一方面造成了資源的浪費，另一方面也降低了OLAP的實時性。對于用戶而言，如果能使用同一套標準的語法和規(guī)則來進行數(shù)據的讀寫和分析，會有更好的體驗。
4、在未來分布式數(shù)據庫系統(tǒng)上，主從日志同步這樣落后的備份方式會被Multi-Paxos / Raft這樣更強的分布式一致性算法替代，人工的數(shù)據庫運維在管理大規(guī)模數(shù)據庫集群時是不可能的，所有的故障恢復和高可用都將是高度自動化的。