爲何是NewSQL？

想必看到此篇的同窗對於newSQL已經不是很陌生了，那麼直接進入今天的主題：
mysql的問題在哪？
1、不能經過mysql的server把InnoDB變成一個分佈式數據庫。
由於mysql生成的執行計劃是個單機的
2、一個分佈式的plan執行起來很複雜且低效。
好比使用分佈式方案Proxy，由於它不支持分佈式的transaction，也不支持跨節點的join
3、異步或半同步複製
由於有時候數據出問題你不知道是否應該切換節點，由於異步的方式會致使一部分數據「還在路上」。尤爲是對於多數據中心的複製和數據中心的容災。
而NewSQL真正發展起來是在2014年底到2015年初的時候，Raft論文發表以後，真正的NewSQL理論基礎就基本確立了。
那麼從技術實現的角度分析，爲何這樣的技術會誕生呢？它又能解決哪些過去的產品解決不了或者不是最優方案的場景呢？

首先，舉一個範圍查詢的例子，若是要查找一個班級裏成績在80-90之間的學生，那麼經過KV的API的要很麻煩的，可是SQL的優化器就很容易解決此類問題，寫一句SQL就能夠搞定。
其次是高可用，將來的系統確定是要設計成Auto-Failover的，即自動恢復，須要人工去幹預的容災系統不是好廚子。

而後針對業務還要說幾點：
好比按照ID去分庫分表，好比使用一致性哈希去指導節點均衡。若是問題上升到了必定的複雜度，若是再使用應用層的程序邏輯來決定數據流向，那麼未免有些low。之後的系統確定是要設計成徹底解耦的，即應用層只負責處理業務邏輯，而數據流轉所有交由基礎設施層來決策。

下面先介紹下Google Spanner / F1，
http://www.valleytalk.org/wp-content/uploads/2012/10/Spanner-Chinese.pdf
這是廈大老師翻譯的，很是棒的一篇論文。
如今有個想法忽然冒出來：爲何工業界的論文能夠誕生優秀的產品，而學術界卻一直默默無聞呢？答案在下面連接中能找到：
http://news.zol.com.cn/647/6477905.html

TiDB and TiKV

首先看下他的架構模型：

其中TiKV對應的事Spanner，而TiDB對應的是F1。
F1強調分佈式SQL層實現的方式，這裏最重要的一點是它兼容了MySQL協議，對於遷移來講實在太合適不過了。

再來看下邏輯視圖：

這個系統共分了六層，最底下的實現是RocksDB（基於LevelDB實現，具備高速寫入的特性），在上層的Raft並無實現Transaction，由於此時他須要保證寫入的數據複製了足夠多的副本。以後在分佈式事務知足了以後再加上SQL層。

而後講下擴容：

這個很容易理解，每一個Region的全部副本組成一個raft group，因此一共有三個raft group，在每一個Node上面數據的分佈較均勻。由於每一個region都分佈在了不一樣的節點上，就算一個節點宕機，其餘節點裏的每一個region也會經過raft的選舉策略選出那個備份做爲新的leader，將原leader中reply但沒有commit的log作一個commit+apply，具體細節能夠參考raft官網：https://raft.github.io/#implementations

最後說下分佈式事務模型：

你們應該都知道，分佈式事務的實現基本都是2PC的，也有2+xPC的，1PC很難作到，除非你在級別上作弱化，若是隔離級別要求很高，1PC是不太好作的。TiDB有一個TiKV driver，能夠很好的將SQL語句落到存儲層再映射到KV上面。對外的編碼格式是Google Protocol Buffer。