为何是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。