2016年，分布式数据库的那些事儿都在这里！
编辑｜木环
回复：数据库，获取完整视频回顾。
戳阅读原文，获得短信提醒，不错过下次直播！
我简单说一下今年我觉得印象比较深刻的几个事情：
Facebook 和 Percona 合作 MyRocks 正式进入市场
MySQL Group Replication 发布, 基于选举的 Replication 方案正式进场
Hive 2.0 的发布，新的 feature 和性能提升让我蛮惊艳的
RethinkDB 的落幕
CockacheDB 、 TiDB 这类的 NewSQL 在社区展露头角
SycallaDB 的发布，让我看到了性能提升上的一些新的思路
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 我觉得最大的问题就是编程的模型过于简单，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 的一个主要原因。
趋势从不同角度来看是不太一样。我们看待数据库发展趋势是从我们过去几年中在企业级业务场景实践的角度出发。
最近几年,如互联网+、软件国产化、O2O、五新(新零售、新制造，新金融、新资源、新技术)、工业4.0等主题接连提出来，并且在各个行业落地，给数据库带来了巨大机会，具体包含3个方向：1.远超单机数据库容量的数据存储和访问峰值，2.实时数据分析检索(OLTP兼顾OLAP)，3.更高级别的容灾需求。
这3个方向对数据库发展提出了更高要求，包括：
数据存储和服务的扩展能力成为一个基础选项；
对数据库实时并行计算能力有了更高要求；
存储多样化和一体化，行存+btree索引演化为行列混合，btree、倒排、bitmap等多种索引混合的架构，同时对用户接口保持一致；
同城、异地容灾成为标配，数据不丢，多活变成一个可实现的选项；
更加注重学习曲线的平缓，交互协议、操作接口兼容传统单机数据库，功能上也尽可能和单机数据库保持一致，比如函数、JOIN、子查询、事务等。
过去一年，我们在公共云上以及企业私有输出做了大量的工作，也收获了很多业务的信任。这项信任来自我们产品对业务需求的满足，也来自我们团队对分布式数据库领域问题较强的把控能力。
业务的需求起源于各个行业既有的发展瓶颈和新业务形态所带来的技术压力，比如零售行业的库存问题，政务层面的数据逻辑大集中问题，而新业务形态的技术要求也与现有能力存在代差，特别是在数据库领域的技术要求。
但是对于数据库技术而言，首先需要满足一项最朴素的要求：必须是稳定、可靠的。包括：
数据不丢(任何故障下)；
服务中断时间可控；
完备的权限体系；
完善的监控告警体系。
过了这关，然后是对分布式数据库核心能力扩展性的验证，在具体业务场景下，是否确实能够突破单机瓶颈，弹性是否足够平滑，过程是否存在坑，等等考量点逐一验证。
再者业务对于新技术方案所带来的代价会进行详细的了解和测试，首先产品的边界在什么地方，函数支持度，约束支持度，事务支持度、JOIN的支持度、子查询支持度、DDL/DAL支持度等。另外是价格问题，大部分客户在开始评测或者使用新产品不会投入大量的资金和人员，所以技术的展现输出规模需要非常好的设计，这块我们的做法是在公有云上有一样的产品，并且控制分布式数据库的输出规模和正规性。
易用性层面，用户期望是能够符合云的特性，投入的是机器和硬件，产出的是服务和有效管控，从分布式数据库层面来看，包括生命周期管理、监控告警、异常诊断、备份恢复、资源管控、容灾切换、日常运维(账号权限、DDL、SQL review等)、数据库扩展、日志管理和查询都需要做到产品化。
最后，抛开产品本身的能力，如何实施并且可持续有两条路可以走，一条路是商业化，建立从销售、商务、架构、部署升级、开发、培训、运维和故障处理的正规体系，而另外一条路就是开源。
这个主题聚焦的问题是：传统单机数据库的优势是否加速了业务发展，劣势是否阻碍了业务发展？评估两者对业务发展的利弊大小。
所以传统单机数据库还是能够满足相当大范围的需求，分布式数据库则拓展了业务容量上限，所以我们需要单机数据库，同时也需要分布式数据库。
传统单机数据库优点：
通过半个世纪的发展，单机数据库业务场景非常广泛；
在稳定性、可靠性方面，得到过很好的验证，并且有良好的硬件、系统匹配；
文档和售后支持层面比较全面，成千上万家ISV在围绕传统单机数据库做事，不需要太担心找不到好的技术支持；
开发同学对单机数据库认知非常好，学习曲线底；
沉淀了很多标准，典型如SQL系列标准,XA协议等。
分布式数据库的优点，同时也是传统单机数据库弱点，如下：
分布式数据库天生具备扩展性，静态也好，动态也罢，都能够突破单机容量瓶颈；
分布式意味着计算能力也可以突破上限，也就是OLTP和OLAP一体化成为了可能，普通业务方非常希望数据库是一个all in one的方案，或者说hybrid；
分布式数据库实现的理念突破了瓶颈，不受限于几十年前人们对于数据库的认知，规模更加庞大，性能让人超出期望。
分布式数据库领域的技术方案和产品相比于2015年多了很多(公开的、商业化的)，比如DRDS, TiDB，Oceanbase，TDSQL，MyCAT，GBase, 乃至O记的Oracle 12c sharding等，大部分产品通过share-nothing结构实现扩展性，实现方法上包括中间件+MySQL方案，改造开源数据库比如MySQL的方案，自研数据库服务层+成熟开源存储引擎(RocksDB/TokuDB等)，以及全自研方式，各有特点和侧重点。
而我们DRDS是采用share-nothing结构，并且实现方式上为中间件+MySQL方案，秉承的理念是开放存储架构，站在巨人的肩膀上，专注做分布式这一层。MySQL为我们解决了存储、SQL处理、单机计算模型建立和优化、字符集、事务、容灾等等问题，并且他还在不断进化和丰富。
比如最近5.7支持的json, 加上分布式，则成为另外一个shemafree的MongoDB，支持的GIS,加上了分布式，则进化成容量无上限的地理位置信息数据库, 支持MyRocks(LSM-tree)引擎, 加上分布式，则进化成Hbase(实时写入能力强)，支持列存存储引擎，加上分布式，则是一个优秀的带实时分析能力的数据仓库。
对于分布式数据库的现状，最后总结一下，这是一个充满活力，又需要把握分寸的领域，同时需要更多的同学来参与其中，并且分享、开放、高水平竞争是这个领域的主题。
未来的分布式数据库必定是标准化的，主要针对用户而言，包括交互协议，操作接口等；
未来的分布式数据库必定有统一评测模型和框架；
未来的分布式数据库对于事务的支持是普遍化的，并且强一致事务的难题会被攻克；
未来的分布式数据库能够同时满足部分的OLTP需求和部分的OLAP需求；
未来的分布式数据库同城、异地容灾，多活成为标配。
今日荐文
点击下方图片即可阅读
不管你承认与否，人工智能的时代即将来临