比起传统单机数据库 怎样看待分布式数据库优势与前景？

来源：大数据杂谈 时间：2017-01-09 11:03:49 作者：励强 黄东旭

本文为阿里巴巴中间件团队高级技术专家励强和 PingCAP CTO 黄东旭两位嘉宾在InfoQ大咖说直播中的内容回顾。

　　分布式数据库领域的8年抗战

　　一、2016年数据库趋势

　　趋势从不同角度来看是不太一样。我们看待数据库发展趋势是从我们过去几年中在企业级业务场景实践的角度出发。

　　最近几年，如互联网+、软件国产化、O2O、五新(新零售、新制造，新金融、新资源、新技术)、工业4.0等主题接连提出来，并且在各个行业落地，给数据库带来了巨大机会，具体包含3个方向：

　　1.远超单机数据库容量的数据存储和访问峰值

　　2.实时数据分析检索(OLTP兼顾OLAP)

　　3.更高级别的容灾需求。这3个方向对数据库发展提出了更高要求，包括：

　　数据存储和服务的扩展能力成为一个基础选项;

　　对数据库实时并行计算能力有了更高要求;

　　存储多样化和一体化，行存+btree索引演化为行列混合，btree、倒排、bitmap等多种索引混合的架构，同时对用户接口保持一致;

　　同城、异地容灾成为标配，数据不丢，多活变成一个可实现的选项;

　　更加注重学习曲线的平缓，交互协议、操作接口兼容传统单机数据库，功能上也尽可能和单机数据库保持一致，比如函数、JOIN、子查询、事务等。

　　二、企业级分布式数据库实践

　　过去一年，我们在公共云上以及企业私有输出做了大量的工作，也收获了很多业务的信任。这项信任来自我们产品对业务需求的满足，也来自我们团队对分布式数据库领域问题较强的把控能力。

　　业务的需求起源于各个行业既有的发展瓶颈和新业务形态所带来的技术压力，比如零售行业的库存问题，政务层面的数据逻辑大集中问题，而新业务形态的技术要求也与现有能力存在代差，特别是在数据库领域的技术要求。

　　但是对于数据库技术而言，首先需要满足一项最朴素的要求：必须是稳定、可靠的。包括：

　　1、数据不丢(任何故障下);

　　2、服务中断时间可控;

　　3、完备的权限体系;

　　完善的监控告警体系。过了这关，然后是对分布式数据库核心能力扩展性的验证，在具体业务场景下，是否确实能够突破单机瓶颈，弹性是否足够平滑，过程是否存在坑，等等考量点逐一验证。

　　再者业务对于新技术方案所带来的代价会进行详细的了解和测试，首先产品的边界在什么地方，函数支持度，约束支持度，事务支持度、JOIN的支持度、子查询支持度、DDL/DAL支持度等。另外是价格问题，大部分客户在开始评测或者使用新产品不会投入大量的资金和人员，所以技术的展现输出规模需要非常好的设计，这块我们的做法是在公有云上有一样的产品，并且控制分布式数据库的输出规模和正规性。

　　易用性层面，用户期望是能够符合云的特性，投入的是机器和硬件，产出的是服务和有效管控，从分布式数据库层面来看，包括生命周期管理、监控告警、异常诊断、备份恢复、资源管控、容灾切换、日常运维(账号权限、DDL、SQL review等)、数据库扩展、日志管理和查询都需要做到产品化。

　　最后，抛开产品本身的能力，如何实施并且可持续有两条路可以走：

　　一条路是商业化，建立从销售、商务、架构、部署升级、开发、培训、运维和故障处理的正规体系;而另外一条路就是开源。

　　三、 为什么需要分布式数据库

　　这个主题聚焦的问题是：传统单机数据库的优势是否加速了业务发展，劣势是否阻碍了业务发展?评估两者对业务发展的利弊大小。

　　所以传统单机数据库还是能够满足相当大范围的需求，分布式数据库则拓展了业务容量上限，所以我们需要单机数据库，同时也需要分布式数据库。

　　传统单机数据库优点：

　　1、通过半个世纪的发展，单机数据库业务场景非常广泛;

　　2、在稳定性、可靠性方面，得到过很好的验证，并且有良好的硬件、系统匹配;

　　3、文档和售后支持层面比较全面，成千上万家ISV在围绕传统单机数据库做事，不需要太担心找不到好的技术支持;

　　4、开发同学对单机数据库认知非常好，学习曲线底;

　　5、沉淀了很多标准，典型如SQL系列标准、XA协议等。

　　分布式数据库的优点，同时也是传统单机数据库弱点，如下：

　　1、分布式数据库天生具备扩展性，静态也好，动态也罢，都能够突破单机容量瓶颈;

　　2、分布式意味着计算能力也可以突破上限，也就是OLTP和OLAP一体化成为了可能，普通业务方非常希望数据库是一个all in one的方案，或者说hybrid;

　　3、分布式数据库实现的理念突破了瓶颈，不受限于几十年前人们对于数据库的认知，规模更加庞大，性能让人超出期望。

　　四、分布式数据库的现状

　　分布式数据库领域的技术方案和产品相比于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需求;

　　未来的分布式数据库同城、异地容灾，多活成为标配。

　　作者介绍

　　励强，阿里巴巴中间件团队高级技术专家，6年分布式数据库领域经验，阿里中间件数据层团队leader。带领团队在阿里集团内和阿里云上开展分布式数据库业务，产品包括TDDL、DRDS、精卫等分布式数据库领域相关产品，阿里集团去Oracle主要实施同学之一，个人兴趣方面，关注欧洲足球联赛，切尔西球队粉丝，FIFA、日系RPG(DQ,FF)游戏爱好者。

　　2016 数据库技术盘点

　　一、2016 数据库圈盘点

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

　　Facebook 和 Percona 合作 MyRocks 正式进入市场

　　MySQL Group Replication 发布， 基于选举的 Replication 方案正式进场

　　Hive 2.0 的发布，新的 feature 和性能提升让我蛮惊艳的

　　RethinkDB 的落幕

　　CockacheDB 、 TiDB 这类的 NewSQL 在社区展露头角

　　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数据库的弊端

　　NoSQL 我觉得最大的问题就是编程的模型过于简单，NoSQL 不会取代支持 SQL 的系型数据库，但是很多场景 NoSQL 是更合适的选择，这个是和业务相关的，比如，如果 Redis 也算 NoSQL 的话，很少有数据库能直接取代它。

　　NewSQL 的兴起，NewSQL 的目标(完美型)

　　另一方面， 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 的一个主要原因。

　　作者介绍

　　黄东旭，热爱画画，美剧，摇滚乐，但更爱写代码的狂热开源爱好者，知名开源软件作者，代表作品分布式 Redis 缓存方案 Codis，以及分布式关系型数据库 TiDB。曾就职与微软亚洲研究院，网易有道及豌豆荚，现任 PingCAP 联合创始人兼 CTO，资深基础软件工程师，架构师。擅长分布式系统以及数据库开发，在分布式存储领域有丰富的经验和独到的见解。

　　答疑部分:以下来自直播中的答疑环节

　　1 云计算会不会让 DBA 失业?

　　励强：5 年之内，我觉得 DBA 对于基础 DB 运维和开发支持还是会大量存在，一个原因是云产品、新技术的成熟和触达业务需要有相当长的时间，另外一个原因是业务规模和广度还在不断扩大，需求缺口还在不断扩大。

　　而未来 10 年内，DBA 职责和能力模型会发生一些改变，具备专业 DB 知识，同时具备开发系统工具以提升运维、诊断和业务开发效率的能力，工作内容、职责上会更加丰富和深入。

　　数据库问题会一直存在，除非达到相当先进的智能化，否则 DBA 这个职业会一直存在。

　　黄东旭：我个人看法比较偏激一些。在我看来 DBA 可能会越来越转向 SRE 和 DevOps 这样的角色。未来，在一个巨大规模的数据库集群上面，人能做的事情其实是越来越少的，比如去运维一个几千规模的数据库集群，每天都有可能发生宕机、磁盘损坏、网络的抖动各种各样的问题，而人所能拯救过来的问题其实越来越少。我认为未来数据库需要能自己运维自己、自己去修复自己，人在里面的角色基本上就是添加机器、下线坏机器这样的一个角色。DBA 会分成两条路线，第一条是去做性能调优，针对业务场景写出更好的 SQL;第二条就是能够走向 SRE 的道路，去做 Cloud 的运维或者开发一些面向云的工具。

　　2 CAP 理论的理解?

　　黄东旭：CAP 理论中的 C，我们首先抛开不论是不是副本实现。单纯地讲，写入数据之后再读出来，如果读到新的值不一样，就是不满足 C。多副本的情况下，并不是说每个副本的数据都完全一致才叫满足 C。而是说提供给用户的接口是满足强一致的情况下，我们就可以说是满足 C 的。比如写入一条数据有三个副本，有两个已经写入了，第三个是通过异步的方式;这时候leader 或者某一个访问存储的节点宕机了，这时候如果还要满足 C 的话，这个时候的业务请求一定要从更新的负载上去给你提供服务，而不是旧的那个区给你提供服务，所以如何保证在failover 的过程中，出现网络分区的情况下，还能让更新的数据返回。(像 Raft Paxos 解决 C的问题。)

　　在落地 CAP 的时候，PingCAP 遵循的原则是强 C 和强 P，A 是永远不能达到完美的。在没有Raft 和 Paxos 这种高可用的模型的时候，原来是使用的主从模式，主挂了，让从起来当主，其实还是要有 DBA 来 check 有无数据丢失、数据有没有同步完、人工地去把它提上来等，但是这个故障恢复的时间就太长了。有了 Raft 和 Paxos 就可以在解决满足强一致的基础上，去自动地把可用性提到一个可用级别;但是这个 A 要变成 HA(High Availability)。

　　励强：有网友刚才发言说，放弃 A 很有特点。确实，一般而言大家都会放弃 C。

　　黄东旭：但是放弃 C 的话，业务就会很难写。

　　励强：是的，需要在业务上对数据中间状态做一定的保护，比如数据状态机等逻辑判定，对业务会有一定的侵入性。

　　3 老师关于 MPP 和 SMP 的理解怎么样?

　　黄东旭：大家在接触分布式 SQL 和 Hive 发现为什么 Hive 这么慢，因为 Hive 是把SQL 转换成 Hadoop 的 Map Reduce 计算，中间结果都是要落在 HDFS 上面的，这样的速度自然就比较慢了。包括后来的 Impala、Presto，跟 Hadoop 不太相关的 Greenplum 包括 Spark SQL;整个像一个流式计算的结构。中间结果并不会强行地写入到 HDFS 或者中间存储上，而是通过Re-shuffle 或是流式节点的直接传递到下一个计算的单位上，这样整体效率就会非常高;然后另一方面就是优化器的(不管是 MPP 也好还是 SMP)，先说 SMP 吧，你怎么把一个分布式也好，一个 SQL 的执行计划能够生成更加并行、可以利用整个集群并发能力去做计算，这么的一个 SQL 优化器，其实这个和单机优化器的思路是非常不一样的。像 SMP 的 SQL 优化器会尽量把查询给 push down，包括谓词下推、聚合算子下推都可以做，但是最后聚合可能还是会受限于单个节点的物理内存等资源。

　　MPP 相当于把单点聚合的问题让这个集群去承担，所以本质上它的 SQL 优化器层上的思想和手段是可以复用的。只不过和分布式计算框架，在 SMP 之上去做一层流式计算框架能搞定的事情，但是其实现在就我的观察来说，至少 80% 我们在 TiDB 应用于 OLAP 遇到的场景，SMP 的这个模式基本就够用了。然后 MPP 的需求，我们会做的是能让 Spark SQL 的查询计划直接去 TiKV(TiDB 的存储层)上去直接 load 数据，直接把 Spark SQL 的算子直接在 TiKV 这一层去实现，一份存储多个 SQL 的引擎，相当于那边充当一个很高效 MPP 的 Engine。所以常规的 OLAP 查询可以通过 SMP， 80-90% 都可以满足。

　　励强：相当于把 MPP 的工作外包给 Spark:)

　　MPP 相当于一个计算框架或者计算模型，在 OLAP 领域广泛使用的计算技术已经慢慢在分布式数据库领域(OLTP)有了一些应用，但是在 OLAP 领域计算资源的调度是具有决定性作用，而这个对于分布式数据库(OLTP)来说，目前暂时没看到非常好的实现，这其中的难度在于 OLTP 对于数据计算的实时性是有比较高的要求。

　　DRDS 产品设计之初就将MPP考虑在未来的发展轨道中，通过执行计划的构造分解和传输实现分布式数据检索计算的效果，而现在我们主要把精力集中在 SMP 上，单机并行度的提升存在下行和上行两个角度，下行指并行下发操作，上行指并行进行结果过滤、聚合和计算，其中上行还存在单请求多分片数据并行计算的优化。

　　目前，无论是 SMP 还是 MPP，用户的需求是大量存在的，在做好这些计算优化的同时，我们也可以转变思路在存储模型、索引模型上有更多的探索，或者也可以通过匹配特殊硬件的方式弯道超车，比如使用 FPGA, Fiber Channel 等硬件，也许原先的目标很容易就达到了。

　　4 初学者学习分布式数据库的路径?

　　黄东旭：其实分布式数据库只是分布式系统的一个分支，而且这个分支比较新。初学的话可以先从分布式系统比如存储入手，其实我个人学习的入门路径是，我把当年 Google 的 Map Reduce、Big Table 的几篇论文都看了，看完了之后再看很多系统就明白了大同小异，还有Amazon Dynamo 的一个入门级别论文，包括像 Paxos 和 Raft 的论文等分布式一致性的理论。其实我个人建议，盯着 Google 每年发的论文就好了，其实比较好看懂，而且是经过了大规模生产环境验证的论文。反而是看书和看 Blog 的速度比较慢，我个人是比较喜欢看论文。

　　励强：我的观点不太一样。如果是普通学习者，个人建议先理解传统数据库的设计理念，比如解析器、优化器、执行器、存储模型(行存、列存、page、block 等)、索引模型、计算模型等知识的了解，然后再切入到分布式数据库领域，可以看一些论文，比如 MetaStore、Percolator、Spanner、F1、Dynamo 等等，最后我觉得可以深入到一些优秀开源项目的源代码中，体会关键特性的实现要素，目前单机数据库以及优秀分布式数据库开源项目非常多，最后的最后，如果有机会，还是能够一起共事面对实际场景，解决客户问题，可以投递简历到阿里中间件 DRDS 产品这边：)

　　这样的方式会更加的循序渐进。从我个人的成长经历来看，一开始就看论文或者直接探索分布式数据库是非常吃力的，反倒是了解了单机数据库的实现方式和原理，也体会到这个领域目前所遇到的问题后，再切入分布式数据库领域，就感觉比较自然。

　　注：本文转载自大数据杂谈，作者励强 黄东旭，版权著作权属原创者所有，欲了解更多大数据行业相关资讯，可搜索数据观(中国大数据产业观察网www.cbdio.com)进入查看。

责任编辑：汤德正