2016年，分布式数据库的那些事儿

本文是对InfoQ中文章的内容的一些注释吧，原文作者水平很高，我是小白，自己注释下权当笔记了。

原文链接：http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2650995185&idx=1&sn=f8b6d2c2e8021d8121821aa7aeb296fc&chksm=bdbf01a28ac888b47323777830dd97974b1e25016cda42cef63dd7b817d0c19293f7a792a24a&mpshare=1&scene=1&srcid=0108RCab0YauSJhPgd532NE4#rd

2016年，分布式数据库的那些事儿

一 2016数据库圈盘点

我简单说一下今年我觉得印象比较深刻的几个事情：
1. Facebook 和 Percona 合作 MyRocks 正式进入市场
2. MySQL Group Replication 发布, 基于选举的 Replication 方案正式进场
3. Hive 2.0 的发布，新的 feature 和性能提升让我蛮惊艳的
4. RethinkDB 的落幕
5. CockacheDB 、 TiDB 这类的 NewSQL 在社区展露头角
6. SycallaDB 的发布，让我看到了性能提升上的一些新的思路

注释1. MyRocks
RocksDB是facebook基于LevelDB实现的，目前为facebook内部大量业务提供服务。经过facebook大量工作，将RocksDB为MySQL的一个存储引擎移植到MySQL，称之为MyRocks。
可参考：
http://www.open-open.com/lib/view/open1450007812240.html
http://www.oschina.net/p/myrocks?fromerr=lgIX6UGS

注释2. LevelDB
Leveldb是一个google实现的非常高效的kv数据库，目前的版本1.2能够支持billion级别的数据量了。 在这个数量级别下还有着非常高的性能，主要归功于它的良好的设计。特别是LSM算法。
LevelDB 只是一个 C/C++ 编程语言的库, 不包含网络服务封装, 所以无法像一般意义的存储服务器(如 MySQL)那样, 用客户端来连接它. LevelDB 自己也声明, 使用者应该封装自己的网络服务。
可参考：
http://baike.baidu.com/link?url=9VS5FmyZFhpZ8ptrzshqaq04ea3CO2ZjnYoariHIsUV6310ESOsLsj8yxQ5IaujWevLJ1u60ESjpEWbRoopN0_
http://www.cnblogs.com/lulu/p/4231810.html

注释3. MySQL Group Replication
基于组的复制（Group-based Replication）是一种被使用在容错系统中的技术。Replication-group（复制组）是由能够相互通信的多个服务器（节点）组成的。
在通信层，Groupreplication实现了一系列的机制：比如原子消息（atomic message delivery）和全序化消息（total ordering of messages）。这些原子化，抽象化的机制，为实现更先进的数据库复制方案提供了强有力的支持。
MySQL Group Replication正是基于这些技术和概念，实现了一种多主全更新的复制协议。
简而言之，一个Replication-group就是一组节点，每个节点都可以独立执行事务，而读写事务则会在于group内的其他节点进行协调之后再commit。
因此，当一个事务准备提交时，会自动在group内进行原子性的广播，告知其他节点变更了什么内容/执行了什么事务。
这种原子广播的方式，使得这个事务在每一个节点上都保持着同样顺序。
这意味着每一个节点都以同样的顺序，接收到了同样的事务日志，所以每一个节点以同样的顺序重演了这些事务日志，最终整个group保持了完全一致的状态。
然而，不同的节点上执行的事务之间有可能存在资源争用。这种现象容易出现在两个不同的并发事务上。
假设在不同的节点上有两个并发事务，更新了同一行数据，那么就会发生资源争用。
面对这种情况，GroupReplication判定先提交的事务为有效事务，会在整个group里面重演，后提交的事务会直接中断，或者回滚，最后丢弃掉。
可参考：
http://blog.csdn.net/d6619309/article/details/53691352?locationNum=2&fps=1
http://blog.csdn.net/mchdba/article/details/54318316

注释4. Hive 2.0新特性
可参考：
http://www.36dsj.com/archives/60604

注释5. RethinkDB
RethinkDB最早是作为一个对SSD进行专门优化的MySQL存储引擎出现的，其特点在于对SSD的充分利用。而目前RethinkDB已经脱离MySQL成为一个独立的存储。
但这家公司在16年10月份倒闭了。
可参考：
http://www.oschina.net/news/77860/rethinkdb-collapse

注释6. CockacheDB, TiDB
TiDB 是国内 PingCAP 团队开发的一个分布式 SQL 数据库。其灵感来自于 Google 的 F1 和 Google spanner, TiDB 支持包括传统 RDBMS 和 NoSQL 的特性。
可参考：
https://www.oschina.net/news/80305/tidb-release-rc1
http://www.oschina.net/p/tidb?from=groupmessage&isappinstalled=0

注释7. SycallaDB
没找到什么信息

二、如何看待 SQL on Hadoop?

Hadoop 目前是大数据处理的开源事实标准方案，基于 Hadoop 的数据分析也经历过多年的发展，从最早的手写 MR（Map-Reduce） 开始，不过我相信现在除了很多的非常定制化的场景，直接手写 MR 做数据分析应该已经不多了，毕竟 SQL 是一个更友好的用户接口。
另外从早期的 Hive 开始，到后来的 Impala，Prestro，Hive 2.0，可以看到一个很明显的趋势是从早期的 SQL based on MR 转向到了更现代的 MPP，我认为其实主要的优势还是在于中间结果不落 DFS，以及 Data Pipeline 的普及，同时随着内存越来越大，计算越来越依靠内存的高效的 IO 也有关。
另一方面，目前看来在 SQL on Hadoop 领域在 CBO（基于代价的查询优化器）上其实目前来说并没有做得太好的方案，Apache Calcite 算是个不错的尝试，但是仍然有很长的路要走。目前 SQL on Hadoop 这方面我比较看好的是 Spark SQL，并不是说目前 Spark SQL 的技术最先进什么的，从社区的活跃度，几个赞助商的投入来看，并不是其他几个项目可以比拟的。
但是这类 SQL on Hadoop 一个比较大的问题，就是仍然还是在 OLAP 领域厮杀比较多，对于数据库的另一方面 OLTP 其实一直以来都是一个比较大的空白。过去也有人在 Hadoop 上进行 OLTP 的尝试，比如 Apache Trafodion，但是由于 Hadoop 本身的一些性能问题和分布式事务带来的开销，另外也是兼容性上的一些问题，并没有成为新一代 OLTP 的标准。
我对于 SQL on Hadoop 的看法就是，目前 OLAP 做得挺棒，但是渐渐会发现新的方案对于 Hadoop 并非强的依赖，比如 Spark，开始在慢慢弱化 Hadoop 本身的存在感，更像是 SQL on X，另一方面 OLTP 我没看到什么机会。

三、数据库和数据仓库的未来

我个人认为数据库和数据仓库会走向一个融合的道路，目前大多数的公司和业务在做数据分析的时候，都是离线倒腾一份数据到数据仓库中，好一点的通过 kafka / spark streaming 进行增量的同步，但是因为数据库和数据仓库的异构性 ETL 的过程是很难省下来的，而且数据仓库很少和数据库共享存储，基本上一份数据，要在两边都存一份；
另一方面，对于很多公司来说，数据仓库的维护成本也是很高的，比如 Hadoop 的众多组件，JVM 的调优等等，用得很痛苦；在 OLTP 这边，在数据量膨胀的过程也是非常痛苦，分库分表，中间件什么的对业务层的倾入性是一个大问题，另外可维护性也比较差；
所以我一直在想，数据库和数据仓库应该在未来会融合，为什么不同一份存储，多个异构的查询引擎，我当然明白行式存储和列式存储有各自适用的优势场景，但是对于 OLTP 来说，极宽表（1000 columns+）的场景是非常少的，而且在这种场景下使用列式存储更新的代价非常高。
但是从 OLAP 的场景来说，大家似乎有些一刀切。其实在我们的观察来看，并非所有的分析场景都是那种上万列的大宽表，并没有到非列存没法搞的地步，对于 80% 的 Ad Hoc （准实时）分析来说，如果在数据库层面上能进行高效的实时分析并且不影响正常的 OLTP workload，会极大的减轻开发者的负担，新一代的数据库我认为应具备“ 100% OLTP + 80% OLAP；同一份存储，多个查询引擎”这两点特性，真正 20% 复杂的分析场景才需要同步到第三方数据仓库中，这也是我们在努力的方向， TiDB 就是这么一个目标的产物。

四、NoSQL 和 NewSQL

NoSQL 数据库的弊端，NewSQL 的兴起，NewSQL 的目标（完美型）

NoSQL 我觉得最大的问题就是编程的模型过于简单，NoSQL 不会取代支持 SQL 的系型数据库，但是很多场景 NoSQL 是更合适的选择，这个是和业务相关的，比如，如果 Redis 也算 NoSQL 的话，很少有数据库能直接取代它。
另一方面， SQL 是一个更易用更标准的接口，还有 ACID 事务什么的也是；NewSQL 的兴起其实也是一个必然，大家在这么多年的 NoSQL 浪潮中发现原来 NoSQL 也并非万能，有些业务场景确实就是一行 SQL 顶百行代码，但是数据量已经今非昔比，数据库的分布式问题是一定要解决的，那么就很自然的会探索如何将关系模型和在 NoSQL 运动中积累下来的分布式方案融合起来。
Google Spanner 和 F1 是一个很好的榜样，第一次让我看到了方才说到的融合的可能性，我认为是目前唯一能 Scale 的 NewSQL 模型，当然我们的 TiDB 作为 Spanner 和 F1 的开源实现，其中的复杂度也是比普通的 NoSQL 高一个数量级的，不过为了实现这些特性这也是必经之路。所以，我觉得 NewSQL 的目标有几个：
完整的 SQL 支持，并非分库分表中间件这种受限制的 SQL
ACID事务的支持，支持透明的跨行事务
高可用和 Auto Failover，无需 DBA 介入，数据库集群应该能拥有自我修复的能力
弹性伸缩能力，集群吞吐和容量随着计算资源的增加而线性扩展

五、技术上需要攻坚的挑战

我简单介绍一下几个比较重要的点，或者说对于 TiDB 的一些未来的工作：
1.刚才提到过的更好的分布式基于代价的 SQL 优化器是一个很前沿课题，TiDB 正在做这方面的尝试，并且已经有了不错的效果。在 TiDB 里我们用了很多近几年比较新的优化器理论，当然这个领域也是一个没有尽头的领域，需要持续的研究。
2.SQL 执行器方面，OLAP 领域常用的比如 Code Gen 和 Vectorize 如何在行式存储的模型上实施，这对存储节点快速的检索和聚合意义很大。
3.另外对于刚才提到的另外 20% 的复杂分析型 OLAP 业务，我们更看好 Spark。这样一来，如何让 Spark SQL 高效的下推算子到我们的存储节点上，如何跟 Spark DNN 高效的连接，省去额外导入导出数据和 ETL 的麻烦，这个工作我们也在做。
4.分布式事务模型上的创新。即使是传统的两阶段提交对于不同类型的 workload 也是可以有不同的优化方向的，比如对于大多数 workload 都是大事务，和都是小事务的场景就有不同的优化方案。
5.Cloud-Native，如何和云的架构更好的整合。我相信未来分布式数据库的部署一定会和云紧密的绑定，其实更具体点，就是和调度器的整合。目前我更看好 Kubernetes，但是现有的调度器基本没有办法支持数据库这类带状态的服务的透明调度，虽然 k8s 有 petset 这类的方案，但是还不算成熟。如果基于 k8s 的 controller 来开发的话，侵入性又太大。
还好，目前 CoreOS 的 operator 的方案让我看到了曙光，我们也在积极的开发 tidb-operator 以支持 k8s 的调度，但是目前 k8s 还有一些额外的问题导致并没有办法大规模的部署 TiDB，问题主要出现在 k8s 的虚拟网络层，这个我相信 k8s 的社区会在 2017 年解决。
6.利用硬件解决一些软件难以解决的问题。目前我们正在尝试将一些逻辑在 FPGA 上实现以达到更好的 IO 效率和节省主 CPU 的效果，这个对于性能的提升是非常明显的。未来更进一步，在 FPGA 上实现 SQL 的查询、聚合算子也是很自然的事情；另外一方面随着 NVMe SSD 的普及，我相信磁盘的随机写入的问题将不会像机械硬盘时代那么大，这也是我们选择 LSM-Tree 的一个主要原因。