目前主流的數(shù)據(jù)庫或者NoSQL要么在CAP里面選擇AP，比較典型的例子是Cassandra，要么選擇CP比如HBase，這兩個是目前用得非常多的NoSQL的實現(xiàn)。我們的價值觀一定認為未來是分布式的，一定是盡量傾向于全部都擁有，大部分情況下取舍都是HA，主流的比較頂級的數(shù)據(jù)庫都會選擇C，分布式系統(tǒng)一定逃不過P，所以A就只能選擇HA。現(xiàn)在主要領域是數(shù)據(jù)庫的開發(fā)，完全分布式，主要方向和谷歌的F1方向非常類似。
　　目前看NewSQL代表未來（Google Spanner、F1、FoundationDB），HBase在國內(nèi)有六個Committer，在目前主流的開源數(shù)據(jù)庫里面幾乎是最強的陣容。大家選型的時候會有一個猶豫，到底應該選擇HBase還是選Cassandra。根據(jù)應用場景，如果需要一致性，HBase一定是你最好的選擇，我推薦HBase。它始終保持強一致，我們非常喜歡一致性，喪失一致性的時候有些錯誤會特別詭異，很難查。對于Push-down特性的設計其實比較好，全局上是一個巨大的分布式數(shù)據(jù)庫，但是邏輯上是分成了一個個Region，Region在哪臺機器上是明確的。
　　比如要統(tǒng)計記錄的條數(shù)，假設數(shù)據(jù)分布在整個系統(tǒng)里面，對數(shù)十億記錄做一個求和操作，就是說不同的機器上都要做一個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 沒有約束其實是很嚇人的一件事情，當然沒有約束也比較爽，就是后期維護十分痛苦，規(guī)模進一步擴大了之后又需要遷移到 SQL。
　　現(xiàn)在無論從品質還是速度上要求已經(jīng)越來越高，擁有SQL的同時還希望有ACID的東西（OLAP一般不追求一致性）。所以TiDB在設計時就強調(diào)這樣的特點：始終保持分布式事務的支持，兼容MySQL協(xié)議。無數(shù)公司在SQL遇到Scale問題的時候很痛苦地做出了選擇，比如遷移到HBase，Cassandra MongoDB已經(jīng)看過太多的公司做這種無比痛苦的事情，現(xiàn)在不用痛苦了，直接遷過來，直接把數(shù)據(jù)導進來就OK了。TiDB最重要的是關注OLTP，對于互聯(lián)網(wǎng)業(yè)務來說通常是在毫秒級內(nèi)就需要返回一個結果。
　　我們到目前為止開發(fā)了六個月，開源了兩個月。昨天晚上TiDB達到了第一個Alpha的階段，現(xiàn)在可以擁有一個強大的數(shù)據(jù)庫：支持分布式事務，始終保持同步的復制，強大的按需Scale能力，無阻塞的Schema變更。發(fā)布第一個Alpha版本的時候以前的質疑都會淡定下來，因為你可以閱讀每一行代碼，體驗每個功能。選擇這個領域也是非常艱難的決定，實在太Hardcore了，當初Google Spanner也做了5年。不過我們是真愛，我們就是技術狂，就是要解決問題，就是要挑大家最頭痛的問題去解決。好在目前阿里的OceanBase給我們服了顆定心丸，大家也不會質疑分布式關系型數(shù)據(jù)庫是否可行。
　　TiDB名字由來
　　為什么叫TiDB？大家起名字的時候特別喜歡用希臘神話里面的人物，但幾乎所有的希臘神話人物的名字都被別的項目使用了，后來我們就找了化學元素周期表（理工科男與生俱來的特征），化學元素周期表里找到一個不俗且又能代表我們數(shù)據(jù)庫特性的元素-Ti 。Ti是航空航天及航海里面很重要的設備都會用到的，特別穩(wěn)定，也比較貴。
　　
　　TiDB的系統(tǒng)架構圖
　　TiDB怎么支持MySQL這個協(xié)議？這里會有一個協(xié)議解析層，它的作用就是去分析MySQL協(xié)議，轉成內(nèi)部可以識別的分發(fā)給自己的SQL Layer。當SQL Layer 拿到這個語句之后會把它拆成對應的分布式KV操作，所以這里會有一個Transactional KV Storage。接下來是在KV基礎上增加事務的支持，再往上是普通的KV操作，理論上KV選什么都可以，如果選的是HBase有一個好處，它本身就是分布式，省掉分布式的工作。目前我們在小米的Themis基礎上做了些優(yōu)化和改進，和我們TiDB做了一個很好的結合。后期我們有一個計劃，準備自己重寫一套底層的分布式KV，把HBase換掉。因為HBase對于Container不友好，加上GC也是讓人比較討厭的問題，壓力比較大的時候GC延遲會加長。

普通下載普通下載

相關電子資料下載

• 常用于緩存處理的機制總結 如何避免緩存雪崩問題？ 24
• SpringBoot物理線程、虛擬線程、Webflux性能比較 37
• mysql經(jīng)典面試題及答案 63
• 人大金倉獲評“2023年度軟件和信息技術服務名牌企業(yè)” 100
• 聊聊即將到來的MySQL5.7停服事件 179
• 基于Prometheus開源的完整監(jiān)控解決方案 25
• 事務性日志結構文件系統(tǒng)的設計及實現(xiàn) 58
• SQL關系數(shù)據(jù)庫和實時數(shù)據(jù)庫的區(qū)別 62
• 什么是SQL注入？Java項目防止SQL注入方式 37
• 基于控制臺的通訊錄管理系統(tǒng)功能介紹 59