目前主流的資料庫或者NoSQL要麼在CAP裡面選擇AP，比較典型的例子是Cassandra，要麼選擇CP比如HBase，這兩個是目前用得非

常多的NoSQL的實現。我們的價值觀一定認為未來是分散式的，一定是儘量傾向於全部都擁有，大部分情況下取捨都是HA，主流的比較頂級的資料庫都會選擇

C，分散式系統一定逃不過P，所以A就只能選擇HA。現在主要領域是資料庫的開發，完全分散式，主要方向和谷歌的F1方向非常類似。

目前看NewSQL代表未來(Google Spanner、F1、FoundationDB)，HBase在國內有六個Committer，在目

前主流的開源資料庫裡面幾乎是最強的陣容。大家選型的時候會有一個猶豫，到底應該選擇HBase還是選Cassandra。根據應用場景，如果需要一致

性，HBase一定是你最好的選擇，我推薦HBase。它始終保持強一致，我們非常喜歡一致性，喪失一致性的時候有些錯誤會特別詭異，很難查。對於

Push-down特性的設計其實比較好，全域性上是一個巨大的分散式資料庫，但是邏輯上是分成了一個個Region，Region在哪臺機器上是明確的。

比如要統計記錄的條數，假設資料分佈在整個系統裡面，對數十億記錄做一個求和操作，就是說不同的機器上都要做一個sum，把條件告訴他要完成哪些任務，他給你任務你再彙總，這是典型的分散式的 MPP，做加速的時候是非常有效的。

2015年HBaseConf 上面有一句總結: “Nothing is hotter than SQL-on-

Hadoop, and now SQL-

on- HBase is fast approaching equal hotness status”， 實際上SQL-on-HBase 也是非

常火。因為 Schema Less 沒有約束其實是很嚇人的一件事情，當然沒有約束也比較爽，就是後期維護十分痛苦，規模進一步擴大了之後又需要遷移

到 SQL。

現在無論從品質還是速度上要求已經越來越高，擁有SQL的同時還希望有ACID的東西(OLAP一般不追求一致性)。所以TiDB在設計時就強調這

樣的特點：始終保持分散式事務的支援，相容MySQL協議。無數公司在SQL遇到Scale問題的時候很痛苦地做出了選擇，比如遷移到

HBase，Cassandra

MongoDB已經看過太多的公司做這種無比痛苦的事情，現在不用痛苦了，直接遷過來，直接把資料導進來就OK了。TiDB最重要的是關注OLTP，對於

網際網路業務來說通常是在毫秒級內就需要返回一個結果。

我們到目前為止開發了六個月，開源了兩個月。昨天晚上TiDB達到了第一個Alpha的階段，現在可以擁有一個強大的資料庫：支援分散式事務，始終

保持同步的複製，強大的按需Scale能力，無阻塞的Schema變更。釋出第一個Alpha版本的時候以前的質疑都會淡定下來，因為你可以閱讀每一行代

碼，體驗每個功能。選擇這個領域也是非常艱難的決定，實在太Hardcore了，當初Google Spanner也做了5年。不過我們是真愛，我們就是

技術狂，就是要解決問題，就是要挑大家最頭痛的問題去解決。好在目前阿里的OceanBase給我們服了顆定心丸，大家也不會質疑分散式關係型資料庫是否

可行。