gistfile1.txt

2016 数据库圈盘点

我简单说一下今年我觉得印象比较深刻的几个事情：

1.  Facebook 和 Percona 合作 MyRocks 正式进入市场
2.  MySQL Group Replication 发布, 基于选举的 Replication 方案正式进场
3.  Hive 2.0 的发布，新的 feature 和性能提升让我蛮惊艳的
4.  RethinkDB 的落幕
5. CockacheDB 、 TiDB 这类的 NewSQL 在社区展露头角
6. 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的兴起，NewSQL的目标（完美型）

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

技术上需要攻坚的挑战

我简单介绍一下几个比较重要的点，或者说对于 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 的一个主要原因。