为什么是NewSQL?

不想你离开。 提交于 2021-02-10 18:35:42

想必看到此篇的同学对于newSQL已经不是很陌生了,那么直接进入今天的主题:
mysql的问题在哪?
一、不能通过mysql的server把InnoDB变成一个分布式数据库。
因为mysql生成的执行计划是个单机的
二、一个分布式的plan执行起来很复杂且低效。
比如使用分布式方案Proxy,因为它不支持分布式的transaction,也不支持跨节点的join
三、异步或半同步复制
因为有时候数据出问题你不知道是否应该切换节点,因为异步的方式会导致一部分数据“还在路上”。尤其是对于多数据中心的复制和数据中心的容灾。
而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。

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!