回顾 | 分布式数据库技术论坛

待我称王封你为后i 2021-12-12 13:43 371阅读 0赞

2019年6月29日，杭州天气炎热，智汇中心11楼的分布式数据库技术论坛也同样热火朝天。

会议于2019年06月29号在杭州市滨江区智汇中心的11楼准时召开，与会的相关人员积极参与，一起聆听了来自PlanetScale、阿里巴巴、Pivotal、沃趣科技的分布式数据库相关议题并进行了热烈的探讨。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70][]

会议开始后，主持人首先致辞欢迎了嘉宾和会场的朋友，会议同时也通过zoom提供了远程访问方式，给不方便现场参加的朋友提供了远程互动的方式。之后主持人介绍了一下分布式数据库论坛的目标和属性。

分布式数据库论坛主要关注的是关系型数据库和分布式技术。关系型数据库通过SQL对应用来提供服务，并且提供了事务的ACID特性，在老一辈DBA的年代，曾经是时代的宠儿。

但是随着互联网的发展和业务的不断成长，传统的数据库，也可以说是单机数据库越来越满足不了庞大的互联网人群访问的需要。大家不得不开始利用NoSQL，map reduce，hadoop等技术来充分利用多机的能力，但是这些技术都需要开发人员做大量的工作，要自己实现大量的代码，原先在数据库管理系统上解决的问题都需要开发人员以相对简单和重复低效的方式来解决。当然，最开始这些技术确实解决了单机上解决不了的问题，大家对新技术的兴趣也非常高，时间长了以后，重复性、人肉的工作越来越多，大家都开始苦不堪言，开始寻找更好的解决方案。

现在腾讯云提供云函数、阿里云提供云API，让开发和业务人员不用关心底层的具体工具和服务来实现自己的目标，也是在这方面的积极探索。天下大势，分久必合，合久必分，现在该是合的时候了。

举个例子，操作系统解决的对单个服务器的透明，要解决进程调度、存储访问、网络连接的问题，而现在最火的k8s的技术，从某种程度上来说不就是在已有的单机操作系统上做了一层软件，要解决的问题其实跟操作系统差不多，不过是在多个服务器上，要解决多个服务器上的存储、在多个服务器上的网络、在多个服务器上的CPU调度等等一些问题。这些问题，将解决问题的范围从单个服务器到了多个服务器。也就是说，就是让应用程序可以面向的是一个“操作系统”，而不是面向每个服务器上安装的多个操作系统，让应用程序和运维人员可以充分利用多个服务器组合起来的能力。

在数据库这一块，现在比较流行的Google Spanner，TiDB这一类NewSQL分布式解决方案；Oracle RAC、Aurora、PolarDB这种对云化环境特别有效的共享存储式分布式解决方案；以及Vitess、MyCat等为代表的分布式中间件都在探索在数据库这一块的分布式是否能解决单机无法满足客户需要的问题。本论坛也主要是学习和探讨这方面相关的知识。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 1][]

作为一个中立和以技术分享、思想碰撞为目标的技术论坛，本次论坛需要特别感谢PlanetScale和Woqutech两家公司，他们帮忙邀请我们的嘉宾，并提供了场地。

## **| 议题** ##

### **Vitess：Stateful Storage on K8s** ###

首先上场的嘉宾是Vitess原厂PlanetScale常驻日本的工程师Toliver Jue，他为大家带来了题为“Vitess：Stateful Storage on K8s”的主题分享。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 2][]

Toliver算半个中国人，他的父亲是香港人，不过他出生在美国，母语是英文，只能通过英语给与会者来分享。Toliver毕业于麻省理工学院，在Google服务了12年，之后加入了同样从Google出来的Jiten创立的PlanetScale来负责Vitess相关模块的开发工作及亚太区的相关事务。

Toliver的演讲风趣而幽默，他主要给大家介绍了Vitess的由来以及使用案例，Vitess是Youtube为了解决不断增长的业务需求来专门设计的数据库中间件，目前来说已经在全球排名最前的应用上使用起来了，包括Cash app、Youtube、slack、Pinterest等，目前在国内的京东也被大规模使用，包括3000+ Databases, 18000+ Tablets。

Youtube加入Google以后，Vitess对Borg进行了深度适配，所以对k8s天生是适配的，目前在京东也是在k8s体系上运行。之后Toliver介绍了业务性能从小到大扩展，Vitess怎么通过读写分离、垂直分片、水平分片来支持，以满足需求的各种场景化案例。

### **Greenplum数据平台新趋势** ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 3][]

Pivotal的资深产品经理吴疆介绍了他负责的其中一个产品Greenplum数据平台。Greenplum 大数据平台基于MPP（大规模并行处理）架构，内置并行存储、并行通讯、并行计算和优化技术，广泛的应用在金融、证券、电信各行各业。在最新的Gartner排名中，Greenplum在经典数据分析领域排名第三位。Greenplum自2015年开源以来，2017年发布了全新的5.0版本，2019年中将发布6.0版本。本次分享结合Greenplum的历史，从五个方面介绍了Greenplum的发展趋势：

1) Greenplum和Postgresql的代码合并（Merge）。从Greenplum开源以来，Greenplum一直致力于上游Postgresql的代码合并（merge），在已经发布的greenplum 5.0是基于postgresql 8.3，即将发布的Greenplum 6.0则横跨postgresql 的6个大版本，基于postgresql 9.4，在Greenplum 7.0则计划将代码merge到greenplum 9.6。随着代码合并的加速，越来越多的postgresql新特性被合并到了Greenplum中

2) 大规模并行处理（massive parallel processing，MPP）架构增强。Greenplum是基于大规模并行处理（massive parallel processing，MPP）架构的数据平台，在即将发布的6.0中，新增了若干MPP架构增强的特性，例如复制表（replicated table），在线扩容，磁盘配额管理等

3) 新的管理工具。介绍了Greenplum的管理运维工具Greenplum Command Center (GPCC)和Greenplum backup/restore工具的新特性

4) 数据分析工具的大发展。介绍了GPText，MADlib，PostGIS等用作文本分析，机器学习，地理信息数据分析的新工具

5) 新的运行时环境。介绍了高性能一体机Greenplum Building Box（GBB）和容器环境下的Greenplum--Greenplum for Kubernetes。

### **全球唯一深度兼容Oracle云原生数据库！POLARDB v2.0重磅来袭** ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 4][]

绛云作为阿里巴巴PolarDB for pg的资深工程师，给大家介绍了PolarDB体系架构，详细介绍了对于传统数据库中不能弹性扩容，TB级实例备份慢，数据库主从延迟高问题等痛点问题在PolarDB中如何解决的。主要强调了最新的PolarDB 2.0对于Oracle兼容性的支持，并对多模计算等业务场景进行了详细的讲解。

### **云原生RDS在K8S中的实现** ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 5][]

麻鹏飞作为沃趣科技QFusion的产品经理，介绍了QFusion怎么基于k8s来实现全球前三大关系型数据库Oracle、MySQL、SQL server的自动部署，弹性扩容和高可用和一致性保证。

QFusion通过CSI标准接口支持多种存储类型，利用Operator构建数据库应用业务，从整体上介绍了怎么基于k8s构建数据库RDS服务的基本注意点。

## **| 圆桌会议及技术讨论** ##

议题分享完成后，四位嘉宾一起跟现场的听众进行了圆桌会议，一起讨论分布式数据库的各种技术问题。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 6][]

### **Spanner和Vitess的取舍** ###

首先主持人先问了Toliver一个“尖锐”的问题。

**Q：**在Google内部既有Spanner又有Vitess，这两个从分布式数据库来说是两个不同的方向，是竞争对手，他们之间的区别是什么，分别有哪些优缺点，Google内部是怎么定义这两款产品的。

**Toliver：**首先指出主持人的一个问题，Google内部并不只有这两款分布式数据库类型的产品，而是有20多种。Google Spanner和CockroachDB、国内的TiDB一样，是基于BigTable来实现的，就像TiDB是基于TiKV实现的，而Vitess是基于成熟稳定的目前最流行的开源数据库MySQL来实现的。Google Spanner专注于数据一致性，QPS要求没有那么高，Youtube之前也考虑过使用Spanner，但是受限于其性能的问题，没有迁移过去。   
Vitess的成本比Google Spanner要低的多，又是基于MySQL来实现的，可以充分利用20多年MySQL成熟的各种数据库特性，性能也能线性扩展，能满足并发要求高、弹性扩展的各种场景。对于绝大部分的公司来说，要实现Google的这种超大规模的集群，代价和成本太高，收益和成本不成正比。所以对绝大部分公司来说vitess是更加现实和可落地的。

### **分布式数据库发展和未来的趋势** ###

主持人接着问了Pivotal的资深产品经理吴疆一个“超大”的问题。

**Q：**请您谈一下当前分布式数据库的发展情况，不同的方向和未来的趋势。

**吴疆**首先从技术人员关心的高可用、性能、数据量介绍了一下分布式数据库需要解决的问题。另外作为资深的产品经理，他提到，要做ToB的生意，让客户认可你的产品的价值，能够从口袋里掏钱，你需要做的远远不止让数据库能及时切换、性能达到业务的要求以及利用多服务器来支持庞大的数据量，你还需要关注企业级特性，比如怎么备份，怎么管理，给客户培训让客户能方便使用，有高大上的架构要做，有脏活累活你也得做。   
**从分布式数据库趋势来说，**** 第一：**从分布式数据库在互联网使用来看，NoSQL等开始加入SQL接口。例如基于hadoop上层开发了hive等。其实原因很简单，SQL深入人心，表达能力强，一个不是DBA出身，甚至不是计算机出生的人都可以利用SQL来完成他的工作。 **第二：**老的数据库是基于老的硬件来做的。不管是Oracle、Teradata还是其他的数据库。现在新Flash硬件、云的环境都对数据库提供了新的挑战，分布式数据库必须要适配新的硬件，跟云环境配合。   
**总结下来两个趋势：**1）SQL回归，用户希望通过SQL这个统一的接口来操作数据库，2）适用新的环境。分布式数据库需要根据新的硬件，云环境来开发和支持。

**沃趣科技的技术总监魏兴华**引用百度前产品经理和首席产品架构师俞军的公式：“用户价值 = (新体验-旧体验) - 替换成本”作为分布式数据库当前发展情况和趋势议题的补充。   
首先，他以沃趣科技的QData的价值为例，说明在替换老的IOE时遇到的困难和阻碍，用户替换为新的架构需要考虑新的产品的价值是否足够大，迁移成本是否足够低以决定是否要替换为QData。   
而在他看来分布式数据库目前还在寒武纪，处在万物生长的时刻，各种新技术层出不穷，但是这些技术目前成熟度还不够，还处在不断进化的过程中。新产品的价值比旧产品价值好才可能会产生替换，现在来看其实新的分布式数据库是否真正可用和它的价值有多大还有待验证。   
而从寒武纪后期的经验来说，要再往前走一步，需要大量的优胜劣汰，在这个过程中锻炼出真金，涌现出真正对客户有价值的产品才是未来。他对这个未来充满信心，也期待能早日拥抱这样的产品。

### **CAP和BASE理论对PolarDB实现的影响** ###

**Q：**对分布式数据库而言，绕不过去的一个话题就是CAP理论。鱼与熊掌不可兼得，PolarDB在具体实现方面是怎么解决的？

**绛云：**CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer's theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：

1.一致性（Consistency） （等同于所有节点访问同一份最新的数据副本）

2.可用性（Availability）（每次请求都能获取响应，不会出错）

3.分区容错性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。）

由于分布式数据库的结构特性，根据分布式系统的CAP定理，实现ACID事务需要付出很大的成本来维护可用性，所以为了保障可用性而总结出一套弱化的事务特性：

1.基本可用（Basically Available）：系统能够基本运行、一直提供服务。

2.软状态（Soft-state）：系统不要求一直保持强一致状态。

3.最终一致性（Eventual consistency）：系统需要在某一时刻后达到一致性要求。

简称BASE，与ACID相对应（acid为“酸”的英文名称，base为“碱”的英文名称）。   
除了上述这些大家耳熟能详的分布式理论以外，在实现过程和用户使用过程，PolarDB还考虑到了因果一致性，写后读一致性，会话一致性，单调读一致性，单调写一致性等的场景。举个例子，如果用户对一致性要求比较高，读到数据就必须从写节点上取，当然性能肯定就无法保证了。而其实PolarDB是支持ms级延迟的可读节点读的，虽然无法保证那么强的一致性，但是读性能的扩展能大大提升。类似的PolarDB还有很多这种设计，来进行设计和实现上的平衡。

### **分布式数据库中间件的全局一致性问题** ###

主持人问完问题以后，就是自由交流时间了，想不到首先发难的反而是场上的嘉宾。

绛云首先向Toliver提出了一个通常分布式数据库中间件的致命问题：vitess是否能保证全局一致性。也就是说，在分布式场景下，多个服务器来进行同一个事务的操作，是否会出现不一致，另外，对应的死锁是否能避免。

Toliver解释，虽然vitess在3.0是支持2PC的分布式事务的，但是对arbitrary deadlock问题目前来说没有太好的解决方案。

### **PolarDB相比Oracle的性能** ###

现场的火药味开始浓烈起来。结果怼人者终被怼，第一个听众也对绛云提出了一个关键的问题。

**Q：**PolarDB号称要替换Oracle，有没有对比过性能列？

**绛云：**首先纠正听众的一个误区，直接的性能对比是不科学的，PolarDB和Oracle没法采用同样的服务器、软硬件，PolarDB采用了自研的Polar Storage存储，并且采用了三副本，SQL和数据量都不太可能一样。目前PolarDB已经支持每秒百万级的查询，已经满足绝大部分业务场景。

### **Vitess和MyCat怎么竞争** ###

**Q：**Vitess相对国内现在已经流行起来的MyCat、DRDS、Sharding Sphere来说是一个新来的竞争者，后续准备怎么应对？

**Toliver：**首先说明Vitess是完全开源的，目前开源的版本跟企业版以及Google内部使用的版本是一致的，大家可以放心使用。第二，目前来说，开源的时代来说各个产品都有其侧重点，各个产品都会相互借鉴，如果说某一个产品全面优于另外一个产品，另外一个产品自然就会被淘汰掉。

### **Greenplum对OLTP的支持程度** ###

**Q：**Greenplum是专门对OLAP来设计的，但是其实现实的环境中，用户既有OLAP又有OLTP类型的需求，在新的版本中Greenplum对OLTP的支持有没有提升，大概是多少。

**吴疆：**在6.0的版本中，对OLTP的支持提升了非常多，目前实测结果是100倍，并且之前的表锁目前被拆分成了行锁，性能会有非常大的提升。

### **Oceanbase和PolarDB的优劣** ###

最后的一个问题也很“劲爆”，听众直接提问绛云。

**Q：**在阿里里面Oceanbase和PolarDB的定位和优劣势，性能到底谁比较强。

**绛云：**首先，这两种分布式数据库的架构不同，Oceanbase是share noting的，而PolarDB是share everything的，两者的定位会有所区别；性能方面，因为两个都是公司的产品，只能说性能都不相伯仲。

## **| 问卷调查及抽奖** ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 7][]

论坛的最后有两位现场的幸运听众抽到了PlanetScale从美国带过来的UBL Speaker，提问的和现场的朋友也拿到了Vitess的T恤，并参与了问卷调查。

从问卷调查的结果来说，阿里、腾讯等的分布式数据库的呼声最高，而丁奇、彭立勋、何登成、梁飞龙等大神的分享也最让人期待。

让我们继续期待下一场分布式数据库技术论坛的盛宴！

\------------------------------------------------------------------------

关注下面技术公众号，回复“技术论坛”

戳链接领取嘉宾分享PPT

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 8][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70]: /images/20211211/c9f65e69e17740c4be9fbe07d11ddd65.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 1]: /images/20211211/c67ac797a7e34c92974dec36583d63ba.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 2]: /images/20211211/4b1bf4de8eba4ca3af79d76de2a4619c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 3]: /images/20211211/c466f52b02b742ed939499a5aa33163a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 4]: /images/20211211/ac2adc8be03748f88b906c84e6a0ca0c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 5]: /images/20211211/2b508418787f445ab67d65e0d637bbc5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 6]: /images/20211211/22811d7a1ffd442783d5d477e4659292.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 7]: /images/20211211/5a36c6d4923e4564970a23be5096828e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ_size_16_color_FFFFFF_t_70 8]: https://img-blog.csdnimg.cn/20190711150921627.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvcXV0ZWNodGVhbQ==,size_16,color_FFFFFF,t_70