eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

July 19, 2019

阿里云李飞飞:云数据库战争下半场的数据库格局

原文链接:https://juejin.im/post/5d15ceb3e51d455d6d535869

【编者按】DTCC 2019已经结束,云栖社区沉淀了很多阿里巴巴所分享的优质演讲整理稿件。这篇转载自IT168&ITPUB执行总编老鱼的公众号,分享给大家。

李飞飞,现任阿里巴巴集团副总裁、高级研究员,阿里云智能数据库事业部总负责人。加入阿里巴巴之前为美国犹他大学计算机系终身教授。研究成果多次获得了IEEE ICDE、ACM SIGMOD最佳论文奖等重要学术奖项。

2018年,李飞飞加入阿里巴巴达摩院,带领团队投入到具有自主知识产权的研究当中。目前,带领的阿里云智能数据库事业部所研发的新一代分布式数据库系统,支撑了阿里巴巴集团的复杂业务、海量数据和双11交易洪峰的挑战,已经被应用于多个城市的智能城市交通网络管理,并服务了金融、零售、物流、制造等行业企业。

2018年,阿里云数据库成功进入Gartner数据库魔力象限,这是该榜单首次出现中国公司,近日,阿里云数据库再次入选Forrester数据库评估报告,成为国内首个获得两大顶级机构认可的科技公司。

2019年5月10日,DTCC 2019(第十届中国数据库技术大会)在北京举办,李飞飞来到现场发表了精彩的主题演讲,并在大会期间接受了IT168&ITPUB执行总编老鱼的深度专访,众多独特观点精彩纷呈。

透露两条信息:

1、PolarDB从去年10月开始商业化到目前,已经成为阿里云上增长最快的数据库产品;

2、AnalyticDB已经通过TPC-DS打榜,做到了世界第一,性价比第一,数据在TPC-DS官网上已发布;

部分精彩观点摘录:

1、目前市面上所有的自研云原生数据库并不是真正意义上的分布式数据库,只能称之为分布式存储的数据库,因此,在下半场这或许会是一个突破点;

2、NoSQL和传统关系型数据库的边界会越来越模糊;

3、有很多厂商说自己的数据库是NewSQL,严格来讲,其实只是在某些维度实现了一到两个点,并没有完美解决NewSQL所有的技术挑战;

4、MongoDB协议修改得非常巧妙,其目的是为了获取云厂商的托管平台去做自己的云托管服务。

5、上半场各云厂商核心的竞争力其实是底层的托管平台,因此,云厂商绝对不可能去托管修改协议后的最新版开源数据库,让自身管控平台开源;

6、下半场两个发力重点:一个是不断地提升托管平台竞争力,二是一定要有自己自研的数据库内核,这是为什么大家都在自研数据库的原因,因为,仅仅靠托管平台的竞争力是拉不开身位差距的;

............................................................

以下是专访原文,为了便于阅读,在不影响原意的前提下,略做修改。

问:请从阿里云数据库产品线重要的产品节点和突破,来谈一谈阿里云在数据库领域的竞争力?

答:众所周知,数据库市场主要分为了以下几个板块:

一个是传统的OLTP,即所谓的RDBMS线上交易系统。最经典的商业的有Oracle、SQL Server,开源的有MySQL、Postgresql,OLTP是阿里云很大的一个板块。

第二个板块是OLAP在线分析,如Teradata,AWS Redshift都属于这个板块。

第三个板块是非结构化、半结构化数据处理需求带来的NoSQL数据库,如Hbase, Cassandra以及现在非常火的MongoDB、Redis都是属于这个板块。

最后一个版块是工具类生态的产品、数据传输、数据备份以及数据管理板块

四大板块下面,又有运维管控平台,也就是俗称的云数据库托管平台,这几个模块就构成了云数据库体系和架构。

以上是数据库市场较大的板块,下面来讲讲阿里云在每个模块里最核心的一些产品和技术积累。首先,是最重要的OLTP板块,可以细分成两类:

一类是托管产品,即第三方的商业数据库和开源数据库,比如像SQL Server、MySQL、Postgresql等,主要是为了给客户提供丰富的选择,使客户可以无缝地把线下数据库迁移上云。

第二类是自研云原生数据库,这里面最主要的重量级产品就是PolarDB。PolarDB是一个基于分布式共享存储的云原生数据库,利用分布式共享存储,带来的好处是存储和计算进行了分离、解耦,解耦以后可以在存储和计算分别进行弹性扩容,做到极致的弹性,对云上客户极具吸引力。因为,云上客户需求一个很关键的点就是按需按量使用,同时进行按需按量计费。

除此之外,PolarDB还有很多技术,比如高可用,利用三副本及分布式数据一致性协议,Parallel-Raft做到金融级高可用的性能,使客户不用担心RPO、RTO的问题。另一个就是在分布式存储以及上面一写多读的多计算节点再上层又做了一个智能化的代理层,可以做到智能、自动的Low balance,计算节点之间的负载均衡分配技术等。这些结合起来,使得PolarDB在云原生上的OLTP数据库处理上具有很大的优势。

比如说,PolarDB可以做到分钟级的弹性缩扩容,从2个Core弹到32个Core只需要大概五分钟,从2个节点弹到4个节点也只需要几分钟,缩扩容从几个TB支持到一百个TB都没问题,可以支持单机点百万QPS处理性能,对云上客户、对弹性、高可用、负载均衡等等都有非常好的解决的方案。在云上的应用是非常有竞争力的,相对于传统On- Premise数据库的架构,PolarDB有非常大的竞争力。

我可以非常自信地说,在阿里云上的PolarDB,无论是从性能、技术上,都已经达到甚至在某些地方超越了AWS Aurora。阿里云也在国际顶级的技术分享会议如SIGMOD、VLDB发表了论文介绍阿里的技术。

从商业上来讲,从去年10月开始商业化到目前,PolarDB已经是阿里云上增长最快的数据库产品,实际使用PolarDB的客户从新零售到金融,再到传统的制造业,各个行业都有,非常多的企业开始将数据库应用迁移到PolarDB上面,这是OLTP板块的情况。

在OLAP板块,我们一样也会分成托管产品和自研产品。托管比如说像传统的BI工具Tableau等,自研最主要的产品是AnalyticDB分析型分布式数据库,其主要特点是行列混存,能够做到多表复杂的中文查询,在秒级甚至毫秒级进行响应。

技术细节不展开讲,讲两个具体的例子,一个是最近做的TPC-DS打榜,TPC-DS大家知道是业界公认的对分析型数据库非常重要的一个Benchmark,我们有一个好消息,AnalyticDB已经通过TPC-DS层层考验,做到了世界第一,性价比第一,这个数据在TPC-DS官网上已经发布。另外,介绍整个AnalyticDB系统的论文,也会在今年的VLDB上宣讲,这两方面都可以从技术上来证明它的先进性。

从业务上来讲,AnalyticDB支持了从税务、城市大脑到公有云,从金融到地产等一系列各行业对海量数据高并发秒级在线分析的诉求,与PolarDB形成了一个天然的互补,从OLTP到OLAP形成了完整的数据链路。

最后,阿里云在NoSQL和工具类方面也有很强的技术布局,主要是通过集团的应用多年锻打出来的一些核心产品。比如,在工具方面我们有DTS数据传输,在不同的库之间,云上云下以及云上不同实例之间进行实时的数据增量一致性备份传输等等,这样可以使得客户快速的进行数据库的迁移,还有数据备份DBS服务。这一系列的产品都是从客户的角度出发,客户需要什么?客户的痛点是什么?我们拿到客户的需求来反推我们技术上要做哪些东西,做到了今天这样一个状态。

问:PolarDB对标的是Aurora,AnalyticDB对标的是Redshift,那么,阿里云数据库研发是有着自己既定的研发策略,还是采取的跟随策略?

答:从客观上来讲,在云上,不仅是数据库板块,从IaaS到PaaS,AWS绝对是先行者。他们的先进经验以及他们避免走过的弯路,我们没有必要一定要走完全跟他们不同的道路,我个人认为还是要集百家之长,要有一种开放的心态。

所以,回答您刚才的问题,我觉得我们一开始是一个Follower(跟随者),这个没什么不好意思承认的。但是我们要从Follower做到超越者,做到leader。通过几年的努力,我们现在已经做到了能够走出一条不同的路,做到了leader位置。那是怎样从Follower变成Leader的?核心诉求是从客户的需求出发。

阿里云有什么优势?阿里云的优势是能接触到中国广大的客户需求。AWS主要的市场在美国,美国客户需求和中国的客户需求有相同的地方,但也有不同的地方,比如说,很多大中型国有企业,美国没有这种组织架构,其需求和美国的商业公司肯定有不同。这是一个很具体的例子,会对我们的技术演进之路提出一些新的思考、新的挑战,也就会使我们最终会走出一条不同于Aurora的技术之路。

另外,我们背靠阿里巴巴集团,身处复杂的生态环境,从电商到线下的新零售,像盒马以及线上娱乐如优酷等等,不仅对我们的技术提出了非常大的挑战,也提供了极为丰富的练兵场。这是我们能够持续走下去并不断衍生出新技术的一个核心保障。

问:到目前为止,阿里云数据库产品线服务总计有多少个?

答:我们现在从托管产品到自研产品,加起来在16个产品左右。这些产品分成四大个板块:OLTP、OLAP 加NoSQL加工具,最后还有一个用户看不到的底层托管平台。底层托管产品不是独立的产品,它就是一个隐形存在。

从数据库产品数量上讲,大家其实大同小异,基本上都是在同一数量级,没有太大的差别。核心的差别是在OLTP和OLAP 板块。

阿里云已经从Follower做到基本与AWS持平,甚至在技术上某些领域做到了领先。比如说刚才讲的OLAP , AnalyticDB的性能已经在TPC-DS上打榜,并排到了第一。通过和AWS官方Redshift对比(在AWS上去买Redshift跑同样的Workload),在TPC-DS的很多的Query,AnalyticDB的性能都是要优于Redshift。

另外,在某些领域,我们也做到了人无我有,即AWS不一定有,阿里云有。比如,在分布式数据库板块,因为集团的"双11"场景需求,我们需要做share-nothing的架构。因此,我们在PolarDB基础上做了PolarDB-X。这样一个share-nothing的分布式架构来支持"双11"海量高并发数据的应用场景支撑。

从AWS的角度看,没有和我们对标的产品。所以,现在云数据库时代是百花齐放、百家争鸣的状态,全球各个厂商,包括阿里,AWS、 Azure和Google大家在某些领域都有各自领先的地方,但在其他领域可能另外一个厂商又有领先的地方。客观来说,阿里云的数据库在国内无论是从市场、技术还是产品方面,都绝对处于领先地位,在国际上也完全是跟AWS拉齐的水平。希望后续竞争到下半场,我们能够在某些领域真正的做到领先者地位。

问:我们知道,像MongoDB等好几家开源数据库厂商都修改了许可协议,主要针对的就是云计算厂商,您觉得,未来两者之间会是一个怎样的关系?这是否是云厂商纷纷发布自研云原生数据库背后的推力之一?

答:这是个非常好的问题,我把这个问题延伸一下,不仅是开源数据库厂商会有动力和压力去做云原生方向的转变,传统的巨头如Oracle也绝对是不遗余力的要去往云原生云数据库这个方向去发展。

云原生数据库有很多技术点,最重要的是弹性、存储计算分离、隔离、多租户还有很重要的一点,要有自己的云托管平台。像Oracle或MongoDB要在云上提供服务,就必须要依赖于云厂商的管控平台,这也是为什么去年MongoDB修改协议的原因。

其实,MongoDB的协议修改得非常巧妙。它允许对MongoDB开源版本进行托管服务,但是如果要基于以后的版本继续提供服务,那么,下面的托管平台就必须要开源。也就是说,如果AWS或者阿里云要继续托管MongoDB的最新版本,底下的管控平台就要开源,开源以后MongoDB可以拿去做自己的云托管服务。事实上MongoDB也是这么做的,研发了自己的Atlas。从MongoDB最新的财报就能看到,其Atlas的增长已经达到了40%多,市场份额从去年年初只有百分之十几,到去年年底,Atlas云托管服务已经增长到MongoD整个营收的30%多。

MongoDB的思路很简单,比起让云厂商提供托管服务并基于MongoDB开源版来占领市场份额,它更希望自己做托管服务,加上自己的内核,来把蛋糕整个切下来,把云厂商定位成只是做IaaS(Infrastructure as a Service)的一层。MongoDB是一种策略,其他的开源数据库厂商包括商业数据库Oracle、SAP, Oracle做Oracle cloud,SAP也做自己的SAP Cloud,它们背后的思路和逻辑都是如出一辙。

云厂商的应对策略也很简单,继续托管产品,但只托管以前版本的产品,即对托管平台没有要求的开源版本,绝对不可能去托管最新版让自身的管控平台开源。云数据库之战上半场各个云厂商核心的竞争力在哪里?其实就是在底下的托管平台。因为,在上半场大家主要还是靠MySQL、PG以及商业的SQL Server这些数据库,来拉动线下的on- premise数据库市场往云上迁移,这是最核心的竞争力。

用户上云有两种选择,要么用托管的MySQL和PG或者SQL Server,或者就是在虚拟机里面自建。

这两个选择对客户来讲,云厂商的价值就是在托管平台来体现的。因为在内核上跟自建完全没区别。托管平台最核心的就是SLA的保证,Service-Level Agreement、RTO、RPO能够做到比自建要好很多或者说和自建SLA一样,但是成本要比它低。

对用户而言,可能需要强大的DBA团队,才能做到与托管平台一样的SLA保证。这可以极大减少运维的投入,这是上半场的态势。

下半场如果MongoDB等厂商做了自己的云托管服务,就会倒逼原来上了云托管服务的客户,回到虚拟机里面自建,把云厂商彻底地定位成IaaS。因为,现在对客户而言,比如说客户用MongoDB的Atlas,那相当于拿到了AWS或者阿里云托管平台提供的SLA的能力,但又不需要给云厂商直接付费,成本上有优势,可能就会去选择自建。

那云厂商怎么应对呢?有两点:第一是不断地提升托管平台竞争力。比如说我们阿里云上有一个叫SDDP的自动驾驶云托管平台,它是利用机器学习人工智能的技术,来对云托管平台上的数据库实例进行自动运维、自动优化等等,来确保托管平台的竞争力。第二个从内核的角度来说,为什么亚马逊、阿里和Google,都在自己做自己的云原生数据库?因为大家意识到,仅仅靠托管平台的竞争力是拉不开升位差距的,所以一定要有自己的自主可控的内核,而且这个内核能够和传统的on- premise DB有性能上的差异。针对云原生的一些特点,能够吸引客户从MySQL、PG、Aurora和MongoDB等迁移到自主开发的云原生数据库上来。

AWS是最典型的,率先推出了Aurora。在NoSQL领域又推出了DynamoDB,在分析领域推出了Redshift。MongoDB修改协议以后,它又推出了自己的DocumentDB。这一系列动作背后的逻辑,和前面讲的是一样的。我个人认为,这场比赛已经进入了下半场。总结来讲,作为云厂商,我们需要在两方面发力,一个是管控平台,通过智能化的手段,提高它的运维能力和效率,另外一个要提升它的安全可靠、可验证。AWS去年推出了QLDB、Quantum Ledger Database,利用区块链里面的Merkle tree技术,对数据库的运维日志进行验证。这样客户上云以后可以来验证运维日志,来确保做到了SLA的保障,这些是从管控平台要做的一些差异化。另外是从内核的角度,不断地去投入内核的研发,以能够和传统的数据库或者新生的像MongoDB数据库内核,进行差异化的竞争。以上是我认为的云数据库战场下半场的一些比较精彩的看点。

问:您提到了云原生数据库,我最近也总是听到几个词,云原生分布式数据库,分布式中间件等。如何去鉴别真正的云原生和伪云原生?

答:这个问题很好,传统的数据库架构是什么?是一种share-everything的架构,比如说一个本地磁盘上面可能有比较大的内存,可以插多个内存条,有比较大的内存池。再上面是计算,有共享的计算状态,有多个 Core。但是很关键的一点是transaction,或者有很多个 query进来,这些transaction和query在整个数据库从存储到内存,再到 Core都是共享状态的,这个就叫share-everything架构,也是传统的数据库架构,像Oracle、SQL Sever都是这种架构。

这种架构有它的优势,是共享状态所以Coordination比较容易做。但缺点是Scalebility(扩展性)会受很大的限制,所以就衍生出了分布式这个概念,分布式最核心的挑战就是要提供Scale Out以及Scale Up的能力。

Scale Out怎么做呢?比较经典的像Google Spanner的做法,是做一个share-nothing,然后做分库分表,做partition,做sharding。在shard之间如果有跨shard的查询和事务,就需要做分布式的查询和分布式的事务处理。这个就是分库分表、Spanner的架构,也是PolarDB-X的架构。这是一种,在share-nothing上面有两个分支,一个是原生的分布式架构。也就是说,实际上在底下是做了sharding和partition的,但客户不需要去感知。对客户来讲,业务逻辑不需要改,如果有分布式的事务处理,分布式查询就会自动搞定。客户不需要去担心怎么去分库分表,去拆分业务逻辑,这是一种。

还有一种就是您刚才问题里面提到的,利用中间件的形式做一个分库分表的解决方案,这个对业务逻辑是有侵害的。这需要数据库的服务商,或者是客户自己要对业务逻辑有很清晰的认识。比如说库存、订单,这两个库是分开的,平时也不会有交集。所以,在业务逻辑上,把它拆分成两个库,这两个库存在不同的节点,这就是一种中间件的解决方式,业界有很多这样的解决方案。

这种方案的好处是比较简单,劣势就是它没有像原生分布式数据库那样,对客户的业务逻辑有侵入式的改造。另外就是,它对事务分布式查询的支持,无法做到像原生的分布式数据库那么好。以上是关于share-noting分布式数据库。

现在,大家讲的所谓叫云原生分布式数据库。我认为这是一个伪命题、伪概念。实际上,现在所有的厂商在云数据库上还没有一个真正的分布式的架构,大部分都是利用分布式存储做共享存储,然后在上面做一写多读。比如PolarDB, Aurora都是这样的架构。它实际上是分布式的共享存储,上面做一写多读存储计算分离,这个是我认为现在所谓的云原生数据库或云原生分布式数据库最典型的一个架构,分布式利用RDMA快速网络做一个分布式共享存储。它看起来像一块盘,实际上它是一个分布式的磁盘,但对上层的kernel来讲,它看起来像一块本地盘。它带来的好处就是物理数据只有一份,它避免了像MySQL、PG这种传统的主备,需要在主库和备库之间做这种物理数据的备份的挑战。主库、备库写的节点和读的节点是一份物理数据,这样就带来很多很多好处。但严格来讲,它是一个分布式存储的数据库,不能把它叫一个分布式数据库。这和我们经典定义的分布式数据库还是有一些区别的,但是现在大家把这个叫云原生数据库或云原生分布式数据库。

在下半场再往前发展会出现一个什么现象?我个人认为,下半场可能会比较有突破点的地方,就是把刚才所说的真正的分布式架构通过shardin架构和云原生分布式共享存储的shared-storage架构(云原生分布式数据库从架构上来讲叫共享存储shared-storage架构)结合起来。这个结构的好处是什么?因为shared-storage用的是RDMA,RDMA是有限制的,比如跨AZ或者说更严重的情况,要跨区的时候,它不可能无限的扩,RDMA共享存储可能只能做到十几个节点、几十个节点。因为一旦跨了network swich以后,RDMA的性能损耗非常大,远程访问不可能做到和本地访问一样快,这样shared-storage架构就有限制。

最经典的Oracle RAC做到 10个节点、20个节点就没办法再往上了,但如果并发高到一定程度或者数量大到一定程度,只能再往上扩,Scale Out要一直往下该怎么办?这时候一定要做分布式partition、sharding这种架构,但是partition、sharding如果不用共享存储的话,带来什么影响呢?每个shard不能做太大,因为单节点就只能存这么多数据。也就是说可能要分很多个shard,分布式的transaction非常多,一旦有distributed commit,性能损耗是非常大的。所以这两个如果能结合起来,有一个好处就是还是可以Scale Out,因为我上面有share-nothing这一层,底下是共享存储的节点,每个shard就可以做得非常大。也就是说对同样的数据来讲,我只需要很少的shard就可以来支持。很少的shard也就意味着分布式跨shard的这种处理会大大减小,分布式的能力会大大提升。所以这两个结合起来,我觉得会是一个比较新、比较有意思的挑战。

问:接下来的一些问题,其实也一直比较困扰我。刚刚您说了分布式,其实过去还有一种分类,比如说SQL、NoSQL、NewSQL,那NewSQL和分布式数据库之间到底是一个什么关系?过去我会把它理解成SQL、NoSQL之外的就是NewSQL,分布式数据库和NewSQL之间是一个包含关系还是其他的关系?

答:这也非常好的一个问题,数据库的同仁和朋友很多时候会有一些混淆的地方。首先NoSQL虽然叫NoSQL,但它实际上含义并不是不要SQL,它是Not Only SQL的缩写,取了个巧叫NoSQL,但它实际上是指不仅仅是SQL的意思。NoSQL的最早发展是怎么来的?实际上来源于传统的关系型数据库,关系型数据库里面因为要保障强一致,也就是ACID,所以Scale Out能力是受到限制的,所以在做Atomicity、 Consistency、Avilability、Durability这些保证的Isolation的时候,和分布式fundamentally是有冲突的,当时的硬件技术、软件技术没有使得传统关系型数据库能够无限的水平拓展。

但以Google为代表的很多互联网公司,在当时确实需要数据和事务处理、查询处理能够无限的水平拓展,因为数据量太大了,每天运行的数据都要存,这是个无限增长的过程。而且这些数据还有个特点,它不一定是结构化的,它可能是半结构甚至非结构数据的,所以,就衍生出NoSQL这个概念。总结来讲,NoSQL最核心的理念就是把传统的关系型数据库里强一致的需求弱化,比如说Isolation level,传统关系型里可能要snapshot isolation,现在只要做到ReadCommitted就行了,只要没有脏读就可以。其它的应用,如果应用层需要更高的隔离机制,那就在应用层去写逻辑,用external Consistence的方法来解决,在数据库层面只需保证没有脏读,牺牲一定的数据一致性,换来几乎无限的水平拓展。这类系统最经典的就是Hbase、Google的BigTable、Cassandra等等,这就是NoSQL的来源。

总结来讲,就是为了提供无限的水平拓展Scale Out的能力,牺牲一定的一致性保障,主要是在Consistency 和Isolation上做一些牺牲,换来无限的水平拓展Scale Out的能力。

NewSQL怎么来的?在NoSQL大概发展了有十年左右,大概是在2008年、2009年那时候出来这个概念,到现在接近10年了。大家发现把一致性等推到应用逻辑层去写还是很多困难的,而且大家发现慢慢地发现对非结构化、半结构化数据也是有强一致性需求的。不是说传统的transaction事务处理只对结构化数据有需求,对非结构化、半结构化没这个需求。所以大家就发现NoSQL系统也得去保证ACID guarantee,所谓的eventual consistency,weak consistency guarantee在很多应用下不适用,所以还是要去做snapshot Isolation,在NoSQL的场景下,这是从事NOSQL的朋友发现有这个需求,从事关系型数据库的朋友发现了什么?比如说MySQL从5.7开始,PG11.0、11.2版本都加入了对Json的支持。典型的半结构化的数据结构,也就是说传统的关键性数据库仅仅支持结构化数据也不行了,它必须也要提供非结构化、半结构化数据的支持,也就是说两边都开始往中间靠。一个有强一致的guarantee,但是它只支持结构化数据,Scale Out能力有限。另外一个支持半结构化、非结构化数据,Scale Out能力很好,但没有一致性保证。两边都牺牲了一些东西,换来自己想要的,但后来越来越发现牺牲的东西客户也是需要的,不仅限于自己所保留的,所以两边都开始补齐缺失的功能。

两者都要有,就变成了"既要......又要......"的状态,这就变成了两方的结合,也就是NewSQL。所以最终我个人认为,如果NewSQL真能发展到最后变成比较常见的一个态势,传统的NoSQL和关系型数据库的边界就会越来越模糊。

也就是说,NewSQL它不等于分布式数据库,分布式数据库可以是NewSQL数据库。NewSQL里面很重要的是Scale Out能力,它首先肯定是一个分布式存储的架构。也就是说它不一定是分布式共享存储,但它肯定是有shard的,有partition。像HBase、MongDB都是shard default的最常见的一个态势。但分布式的数据不一定是分布式的数据库,这要看它是不是真正做到了分布式查询和分布式事务。因为有可能它做了shard,分布式的数据,但是查询和事务是所谓的叫perfect shardable workload。这个事务和查询只用看第一个shard就完成了,另一个查询只看第二个shard。所以虽然它有很多个shard,也有很多个查询和事务,但是具体到每一个查询和事务,都是单个shard搞定的。严格来讲,我认为它不是一个分布式数据库,只是对业务逻辑进行了比较巧的一个partition,使得它可以就完美地去并行处理。

真正的分布式数据库有两个特点:第一,数据肯定是分成了多个shard;第二,它的查询和transaction是有可能产生cross shard这种查询和cross shard transaction,这种叫分布式。传统的NoSQL只支持第一个特点或只支持第二个特点的。支持第二个特点的是牺牲了数据一致性(isolation level),换来了它能够支持分布式事务、分布式查询的能力。

关于NewSQL,我个人认为一个真正好的NewSQL数据库,它必须是支持结构化、半结构化、非结构化数据,这第一点。

第二点是,优秀的NewSQL数据库要有非常好的水平拓展的能力和Scale Out能力,支持分布式查询、分布式事务,同时在单节点上又有非常好的弹性和Scale Out的能力。目前来看,还没有一个数据库可以做到完美的解决所有问题,还有一些其它的技术点像HTAP(混合的事务和分析处理)、读写并存怎样高效的去处理?还有多模multimode、多种数据形态在一个库里,怎样在统一界面去查询?如果能够完美地解决所有这些问题,我认为它就是一个比较优秀的NewSQL数据库。

目前来看NewSQL只是从技术概念上出现的一个东西。严格来讲,有很多厂商说自己的数据库是NewSQL,他可能只是在某些维度实现了一到两个点,但并没有完美解决我们刚才提到的NewSQL所有的技术挑战,所以我觉得,目前我们还是有比较长的路去探索的。


本文作者: 老鱼笔记

Posted by eygle at 12:03 PM | Permalink | IT新闻 (50)

June 26, 2019

NewSQL系统综述-NewSQL到底New在哪里

原作者:Andrew Pavlo(卡内基梅隆大学)Matthew Aslett(451研究所)

转自:https://zhuanlan.zhihu.com/p/23866692

摘要

近年来出现了一种称为NewSQL的新型数据库管理系统(DBMS),它们号称有能力扩展现代在线交易处理(on-line transaction processing, OLTP)系统的工作负载,这对于以前的系统来说是无法做到的。NewSQL这个词是本文的作者之一在2011年的一篇讨论对传统巨头(Oracle,IBM,Microsoft)地位发起挑战的新型数据库系统的商业分析报告中提出来的。另一作者则曾经担任第一代NewSQL DBMS的系统的开发者。从2011年后,一些商业公司和研究项目开始使用NewSQL来描述他们的系统。

鉴于传统的DBMS已经发展了近40年,有必要仔细推敲一下NewSQL的优势是真如他们所说,还是仅仅是一种商业宣传行为。如果真的可以获得更好的性能,那么下一个问题自然就是它们是真的有技术突破,还是仅仅因为硬件方面的发展使得原来的问题已不再是瓶颈?

为了探讨这些问题,我们先讨论了数据库的发展历史,以此理解NewSQL出现的背景和原因。然后从一些细节方面深入讨论了NewSQL的概念,特点,分类,以及在各个分类下面的NewSQL系统。



  1. 数据库管理系统(DBMSS)的简要发展历史

第一代DBMS出现在1960年代中期。IBM开发的IMS用于记录土星V和阿波罗空间探索项目中的供应链和仓储信息。它第一个提出将应用代码和数据操作进行分隔的思想,使开发者只需要关注数据的产生和访问,无需考虑操作和访问这些数据的复杂性。1970年代,IBM和加州大学借鉴IMS的思想分别构建了System R和INGRES,成为第一代关系型的DBMS。其中INGRES很快被其他的大学用于信息系统,接着在1970年代后期进行了商业化。在同一时期,Oracle发布了第一版与System R的设计非常类似的DBMS。其他公司在1980年代早期也纷纷通过推出自己的DBMS系统获得了成功,包括Sybase和Informix。尽管IBM从未将System R开放给公众,但在它的基础代码上于1983年推出了一个新商用的关系型数据库系统----DB2。

为了克服关系模型和面向对象编程语言之间的失配问题,1980年代后期和1990年代早期左右出现了一种新型的DBMS。因为不具备像SQL语言那样的统一的标准接口,所以这种面向对象的DBMS并没有被市场大规模接受。不过,当主要的厂商在十年后添加了对象和XML支持,二十年后添加了面相文档的NoSQL系统之后,这类系统的许多设计思想最终被并入了关系型DBMS中。

在1990年代,另一个值得关注的事件是当今两大主要开源DBMS的诞生。1995年,MySQL起源于瑞典,它建立在ISAM的mSQL系统之上。PostreSQL则是在1994年由两个伯克利大学的研究生在QUEL的Postgres的代码上添加了SQL支持而诞生。

到了2000年代,由于互联网应用的兴起,对系统资源的需求受到了前所未有的挑战。互联网应用需要支持大规模的并发用户,并且要保持永远在线。但是这些新应用的数据库却因为无法支持如此大规模的数据和访问量而成为了整个系统的瓶颈。最简单直接的办法是不断升级DBMS的硬件系统,使用更多的CPU,内存和硬盘。但是这种方法只是提高了性能,并且呈现明显的收益递减效应。更糟糕的是,将数据库从一个机器迁移到另一个机器是一个比较复杂的过程,通常需要较长的停机时间。而这对于Web应用来说是不可接受的。为了解决这个问题,一些公司推出了数据库中间件,对原有的单节点数据库进行数据分片,并存放到由廉价机器组成的分布式的集群里。对于应用程序来说,数据库中间件是一个逻辑上的单节点数据库,但实际上它的存储横跨了多台物理机器。当应用向数据库发起操作时,数据库中间件会自动将操作指令发送到集群中的一个或多个节点来执行。节点执行之后将结果发送回中间件,再由中间件反馈给应用。比较著名的数据库中间件包括eBay的Oracle的集群和Google的MySQL集群。这种方法后来也被Facebook采用,建立了自己的MySQL集群并应用至今。

数据分片中间件在简单操作(如读取或更新单条记录)时能工作得很好,但对于在一个事务中更新多条记录或者JOIN表之类的复杂操作时就无能为力。例如eBay中间件要求开发者在其应用的代码里实现所有的JOIN操作。

于是一些公司不再使用数据库中间件,转而开发自己的分布式DBMS。原因有三个方面:1)传统的DBMS将重点放在一致性和正确性上,牺牲了可用性和性能。但是这种设计上的妥协不能满足Web应用大并发量和时时在线的需求。2)很多人认为使用一个完整功能的DBMS(如MySQL)的开销过大,3)同样地,使用SQL来执行简单的查询也被看做是一种过渡使用。

这些问题引发了2000年代NoSQL运动的诞生。NoSQL系统的关键是它们放弃了传统的DBMS强事务保证和关系模型,通过所谓最终一致性和非关系数据模型(例如键值对,图形,文档)来提高Web应用所注重的高可用性和可扩展性。其中最著名的系统是Google BigTable和Amazon的Dynamo。这两个系统最初并不对外开放(虽然现在都已经变成了云服务),所以其他的用户也创建了自己的开源克隆系统。包括Facebook的Cassandra(基于BigTable和Dynamo),PowerSet的Hbase(基于BigTable)。其他初创公司并没有使用Google或者Amazon系统的副本,但仍遵循了NoSQL的哲学,最著名的是MongoDB。

2000年代后期,出现了更具扩展性并且更廉价的分布式DBMS。使用NoSQL的好处(或者说人们想象中的好处)是开发者可以将精力集中在应用,业务或者组织方面,而不用担心DBMS的扩展性。但是,仍有许多应用不能使用NoSQL。因为它们无法放弃强事务和一致性的需求。通常这些都是需要处理复杂关联性数据的企业级应用(例如财务、订单系统,人力资源系统等)。包括Google在内的一些公司发现采用NoSQL DBMS会迫使程序员在应用开发过程中花费过多的精力来处理一致性数据以提高事务的执行效率。于是唯一的解决之道是:要么购买更强大的单节点机器来垂直扩展DBMS,要么开发自己的数据分片中间件来支持事务。无论哪种方法都非常昂贵,并不是所有人都能接受。在这种环境下NewSQL系统出现了。

  1. NewSQL的兴起

本文关于NewSQL的定义是:这是一类现代关系型的DBMS,旨在为NoSQL的OLTP读写负载提供相同的可扩展性能,同时仍然提供事务的ACID保证。换句话说,这些系统希望达到NoSQL DBMS相同的可扩展性,又能保留从1970年代开始的关系模型和事务支持,使得应用可以执行大规模的并发事务,并使用SQL而不是特定的API来修改数据库的状态。如果应用使用了NewSQL DBMS,开发者不再需要像使用NoSQL一样在应用逻辑里处理最终一致性的问题。我们下面的讨论中,NewSQL的这个解释涵盖了许多学术系统和商业系统。

在2000年代中期出现了数据仓库DBMS,有人认为它们达到了这个标准。例如Vertica,Greenplum,Aster Data)。这些DBMS服务的对象是OLAP系统,并不能认为是NewSQL系统。OLAP DBMS重点是执行复杂的只读查询(例如聚合查询,多维度JOIN等),这些查询需要大量的计算,较长的执行时间,使用超大的数据集,并且每一个查询都是独一无二的。而NewSQL DBMS服务的系统则需要执行读写事务,并具备以下几个特征:1)短生存时间,即没有用户停顿;2)使用索引查询小数据集,不进行全表扫描或者大规模分布式JOIN;3)可重复执行,即不同的输入执行相同的查询。其他人提出了一个更窄的定义,其中NewSQL系统的实现必须使用:1)无锁并发控制方案;2)无共享分布式架构。第三节里列举所有的NewSQL DBMS都具备这个特征,因此我们也认同这个定义。

  1. NewSQL的分类

基于上述的定义,我们可以来看看现在有哪些NewSQL DBMS。为了简化分析,我们将研究对象按照实现方式进行分组。我们分出了三个类:1)使用全新的架构;2)重新实现由Google和其他人在2000年代开发的数据分片基础架构,并在此基础上开发的数据库中间件;3)来自云服务提供商的database-as-a-service(DBaaS),同样基于全新的架构。

本文的两位作者都曾在NewSQL系统分类中考虑了替换现有单节点DBMS存储引擎的方案。最常见的例子是对MySQL默认InnoDB存储引擎的替换(例如,TokuDB,ScaleDB,Akiban,deepSQL)。使用新存储引擎的好处是用户可以获得更好的性能而无需修改应用,并且仍能够继续使用DBMS的周边工具和API。其中最有意思的是ScaleDB,它提供了透明的数据分片方案而不使用中间件,通过在不同的存储引擎之间重新分配执行。不过现在这个公司已经转向了其他问题领域。

除了MySQL,还有其他类似的扩展。Microsoft的内存Hekaton OLTP引擎用于SQL Server时几乎可以与传统的磁盘驻留表无缝集成。其他人使用Postgres的外部数据包装器和API钩子来实现相同类型的集成,但目标却是OLAP工作负载(例如Vitesse,CitusDB)。

现在我们认为这种单节点DBMS的存储引擎和扩展并不代表NewSQL系统,因此在我们的分类中将会省略掉它们。MySQL的InnoDB在可靠性和性能方面获得了长足的进步,因此为OLTP应用切换到其他的存储引擎变得没有十分的必要。我们承认从面向行的InnoDB引擎切换到列存储的引擎对于OLAP负载来说是有意义的(例如Infobright,InfiniDB),但一般来说,为OLTP负载替换MysQL的存储引擎业务是失败的数据库项目的墓地。

3.1 新型架构

这个分类包括了NewSQL系统最有趣的部分,因为它们是全新架构的,从头设计的DBMS。也就是说,跟扩展现有系统不同(如Microsoft的Hekaton for SQL Server),它们从一个全新的起点开始设计,摆脱了原有系统的设计束缚。这个分类中所有的DBMS都采用了分布式架构,对无共享资源进行操作,并且包含支持多节点并发控制,基于复制的容错,流控制和分布式查询处理等组件。使用一个全新的为分布式执行而设计的DBMS的好处是,系统所有的部分都可以针对多节点环境进行优化,包括查询优化,节点间通信协议优化等。例如,大部分的NewSQL DBMS都可以在节点之间直接发送内部查询数据,而不用像一些中间件系统一样需要通过中心节点进行转发。

在这个分类中的所有DBMS(Google的Spanner除外)都管理自己的主存储,有的是在内存中,有的是在磁盘中。也就是说,DBMS负责使用定制开发的引擎在其资源上分布其数据库,而不是依赖现成的分布式文件系统(例如HDFS)或存储结构(例如Apache Ignite)。这是很重要的一个特征,因为这使得DBMS能够"向数据发送查询",而不是"将数据带给查询",这意味着更少的网络流量。因为跟传输数据(不仅仅是元组,还包括索引,物化视图等)相比,传输查询所需的网络流量要少得多。

对主存储的管理还使DBMS可以使用比HDFS中使用的基于块的复制方案更为复杂灵活的复制方案,因此这种DBMS比那些建立在其他已有技术分层上的系统拥有更好的性能。在现有技术分层上建立的系统有所谓的"SQL on Hadoop"系统(如Trafodion),以及在Hbase上提供事务支持的Splice Machine等等,但我们认为这类系统并不是NewSQL。

但是新架构DBMS的使用情况是呈下降态势的。最重要的原因是许多用户担心这项技术太新,没有大规模的安装基础和实际的生产环境的验证。另外就是社群和有经验的用户数量比流行的DBMS要小许多,许多用户有可能无法使用现有的管理和报表生成工具。一些DBMS,例如Clustrix和MemSQL,通过兼容MySQL的网络协议避免了这类问题。

本类案例:Clustrix, Cockroach, Google Spanner, H-Store, HyPer, MemSQL, NuoDB, SAP HANA, VoltDB.

3.2 透明的数据分片中间件

现在有一些产品跟2000年代的eBay,Google和Facebook一样提供数据分片的中间件。用户可以借助它们将数据库分成多个部分,并存储到由多个单节点机器组成的集群中。数据分片比1990年代出现的数据库联合技术更难,因为每一个节点都要运行相同的DBMS,只维护整个数据库的一部分数据,且不能被不同的应用独立访问或修改。

集中化的中间件组件负责分配查询,协调事务,同时也管理数据的位置,复制和跨节点的数据分区。集群典型的架构是在每个节点上都安装一个中介层来与中间件通信。这个组件负责代替中间件在DBMS实例上执行查询并返回结果,最终由中间件整合。对应用来说中间件就是一个逻辑上的数据库,应用和底层的DBMS都不需要修改。

使用数据分片中间件的核心优势在于,它们通常能够非常简单地替换已经使用了单节点DBMS的应用的数据库,并且开发者无需对应用做任何修改。最常见的中间件目标系统是MySQL,这意味着为了保持与MySQL的一致性,中间件必须支持MySQL的网络协议。Oracle提供了MySQL Proxy和Fabric工具来做这些工作,但是其他公司也开发了自己的协议处理器来避免GPL授权问题。

尽管中间件使用户扩展数据库变得更容易,但它们仍需要在每个节点上安装传统的DBMS(例如MySQL,Post供热SQL,Oracle)。这些DBMS采用的是1970年代提出的面向磁盘存储架构,不能像新架构的NewSQL系统那样使用面向内存的存储管理和并发控制方案。以前的研究表明,面向磁盘的架构阻碍了传统的DBMS通过提升CPU核数和内存容量进行向上扩展。中间件方法会导致在分片节点上执行复杂查询操作的时候出现冗余的查询计划和优化操作(即在中间件执行一次,在单节点上再执行一次),不过所有节点可以对每个查询使用局部的优化方法和策略。

本类案例:AgilData Scalable Cluster, MariaDB MaxScale, ScaleArc, ScaleBase.

3.3 Database-as-a-Service

最后一个分类是云服务提供商的NewSQL方案,database-as-a-service,也称为DBaaS。通过这些云服务,用户不需要在自己的硬件设备上或者云端虚拟机上安装和维护DBMS。DBaaS的提供商负责维护所有的数据库物理机及其配置,包括系统优化(例如缓冲池调整),复制,以及备份。交付给用户的只是一个连接DBMS的URL,以及一个用于监控的仪表盘页面或者一组用于系统控制的API。

DBaaS的客户根据他们预计使用的系统资源来付费。因为不同的数据库查询在计算资源的利用上差距非常大,DBaaS提供商通常不会采用块存储服务(例如Amazon的S3,Google的Cloud Storage)常用的依据调用次数计费,而更倾向于采用预付费的订阅方式。即客户指定所需的最大的存储空间,CPU数量,内存空间等,服务提供商则会在服务期间保证这些资源的可用性。

因为从规模经济角度来看,DBaaS的主要提供商也是云计算服务的主要提供商,但几乎所有的DBaaS仅仅提供一个传统的单节点DBMS实例(例如MySQL)。Google Cloud SQL, Microsoft的Azure SQL, Rackspace Cloud Database, 以及Scaleforce Heroku都是这么做的。因为它们同样使用了从1970年代就沿用至今的面向磁盘的存储架构,我们不把这种单实例的系统算作NewSQL。一些提供商(例如Microsoft)对DBMS进行了一些改造,提供了对多租户的支持。

我们仅仅认为那些基于新型架构的DBaaS是NewSQL。最著名的例子是Amazon的Aurora for MySQL RDS,它与InnoDB的最大区别在于它使用日志结构化存储管理器来提高I / O并行性。

另外一些公司的产品并没有自己的数据中心,他们的DBaaS软件建立在公有云平台之上,例如ClearDB能够让客户将其部署在任何的主流云平台上。这么做的好处是用户可以把数据库建立在同一个地区不同的云平台上,以避免由于云服务中断而导致的停机。

Aurora和ClearDB是2016年这个分类下仅存的两个产品。我们注意到其他公司在这个领域的产品都失败了(例如GenieDB,Xeround),原有的客户不得不在他们关闭云服务前迁出他们的DBaaS并寻找下一个提供商。我们将他们的失败总结为超出市场需求,价格上与主要竞争对手没有拉开差距。

分类案例:Amazon Aurora,ClearDB

  1. NewSQL的现状

接下来我们将讨论NewSQL DBMS的特点,以理解这些系统的创新之处。文末所附的列表是我们分析工作的总结。

4.1 主内存存储

自从1970年代以来,所有主流DMBS都采用了面向磁盘的存储架构设计。在这些系统中,数据库的主要的存储位置被假定为在一个可进行块寻址的永久性存储设备上,例如SSD,HDD。因为在这些设备上进行读写操作非常慢,DBMS使用内存来缓存从磁盘读取的块,并缓冲来自事务的更新。这是非常必要的,因为当时的内存非常昂贵,而且容量与磁盘相比非常有限。而现在内存的容量和价格都到达了可以将大部分的数据库都容纳进去的程度。使用内存作为主存储的好处是它支持针对性的优化,因为DBMS不必假设事务需要在任何时间随机地访问不在内存中的数据,许多需要处理诸如缓冲池或者重量级并发控制的组件不再是必须的,所以系统将获得更好的性能。

有一些NewSQL DBMS是基于主内存架构的,包括研究性的系统(例如H-Store, Hyper)和商业系统(例如MemSQL,SAP HANA,VoltDB)。这些面向主内存的系统的性能比面向磁盘的处理OLTP的DBMS要高很多。

将数据库全部放在主内存的思想并不是最新的。1980年代初,威斯康辛-麦迪逊大学的开创性研究为内存数据库DBMS的许多方面奠定了基础,包括索引,查询处理和恢复算法等。同时期第一个分布式主内存DBMS----PRISMA/DB被开发出来。第一个商用的主内存DBMS----Altibase则出现在1990年代。Oracle的TimesTen和AT&T的DataBlitz是这种方法的早期实现。

主内存NewSQL系统一个比较新的点是它有能力将数据库的部分子数据集驱逐到持久存储以减少内存的占用。这种类型的DBMS可以把容量比内存更大的数据库放到内存里,而无需切换回面向磁盘的存储架构。一般的方法是使用一个内部的跟踪机制,一旦发现那些不再被访问的数据元组,就立即将其驱逐出内存。H-Store的anti-caching组件可以将这些不被访问的数据元组存放到面向磁盘的存储器中,同时在数据库中添加一条"墓碑"信息来记录这些数据的位置。当事务试图通过"墓碑"记录访问元组时,它会被终止,然后另一个独立线程会将数据异步地放回到内存中。另一种支持"大于内存数据库"的变体是EPFL的一个学术项目,它在VoltDB中使用OS虚拟内存分页技术。为了避免假阴性,所有的DBMS在数据库的索引中保留了已驱逐元组的键,这使那些具有许多次级索引的应用在内存节省方面的效果变差。虽然不是NewSQL DBMS,Microsoft的Project Sibera for Heikaton的每个索引都保持了一个Bloom过滤器,以减少内存中用于跟踪已驱逐元组的内存开销。

MemSQL采用了完全不同的方法来实现"大于内存数据库"的功能。系统管理员可以手动设定DBMS将某个表存储为列格式。MemSQL并不为磁盘存储的元组在内存中保存任何跟踪元数据。它将这些数据组织在日志结构化存储中以减少更新的开销,这在传统的OLAP数据仓库通常很慢。

4.2 分区/分片

几乎所有的分布式NewSQL DBMS水平扩展方案都是将数据库分割成不相交的数据集,这称之为分区或者分片。

在分区的数据库上进行分布式事务处理并不是一个新的想法。这些系统的许多基本原理来自伟大的Phil Bernstein(和其他人)在1970年代后期的SDD-1项目中的开创性工作。1980年代的早期,两个开创性的单节点DBMS项目,Syste R和INGRES的小组同时创建了分布式版本。IBM的R系统是一个类似于SDD-1的,无共享的,面向磁盘的分布式DBMS。INGRES的分布式版本给人们留下最深刻印象的是它的动态查询优化算法,递归地将分布式查询分解成更小的部分。之后,威斯康辛-麦迪逊大学的GAMMA项目探索了不同的分区策略。

但是这些早期的分布式DBMS并没有真正获得成功,原因有两个。首先是当时硬件成本太高,大部分的客户不可能购买足够多的设备来构建数据库集群环境。其次是应用对分布式DBMS的高性能需求还没有成熟,当时对DBMS吞吐量的最高要求也只有每秒数千笔交易。而我们现在这两点原因都不复存在。构建大规模的数据密集型应用从未如此简单,部分原因是开源分布式系统工具,云计算平台和廉价的移动设备的激增。

数据库的表被水平划分为多个片段,划分的边界基于一个或多个列的值。这些列被称为分区属性。基于这些属性值,DBMS使用范围或散列的分区将每个元组分配给某一个片段。 来自多个表的相关片段被组合在一起以形成由单个节点管理的分区。 该节点负责执行所有访问存储在其分区中的数据的查询。 只有DBaaS系统(Amazon Aurora,ClearDB)不支持此类型的分区。

理想情况下,DBMS应该能够在多个分区上分布式地执行查询,然后将所有结果合并为一个单一的结果返回给调用方。除了支持本地分区的ScaleArc之外的所有NewSQL系统都提供此功能。

分区是许多OLTP应用数据库都具备一个重要特性。这些数据库schema可以转换为树状结构,树的后代与根具有外键关系。然后依据这些关系关联的属性对表进行分区,使得单个实体的所有数据都能位于同一分区。举例来说,一个树的根节点可能是一个客户表,数据库将会根据每一个客户进行分区,将每个人的订单记录和账户信息存放在一起。这么做的好处是它使大部分的事务只需要访问一个单独的数据分区就够了。因为不需要使用原子通信协议(例如2阶段提交)来保证事务在不同节点上正确执行,又进一步减少了网络通信开销。

NewSQL DBMS中,NuoDB和MemSQL采用了与同质集群节点架构采用不同方案。NuoDB指定一个或多个节点作为每个数据库分区的存储管理器(简称为SM)。SM将数据库分成块(在NuoDB的术语中称之为原子)。集群中所有其他的节点被当做事务引擎(简称为TE),它是原子在内存中的缓存。当处理一个查询时,TE通过SM或其他TE可获得这个事务所涉及的所有原子。获得一个写入锁之后,对原子进行的任何更改都将广播给其他的TE和SM。为了避免原子在节点之间来回移动,NuoDB公开了负载均衡方案以确保使用的数据会驻留在同一个TE中。这意味着NuoDB最终会具备与其他分布式DBMS相同的分区,但它不必进行数据库的预分区或对表关系进行预定义。

MemSQL同样使用了一个类似的异构架构,包括只具备执行功能的聚合器节点和存储实际数据的叶节点。MemSQL与NuoDB最大的不同在于二者如何减少从存储节点拉到执行节点的数据量。在NuoDB中,TE会缓存原子来减少从SM中读取的数据量,而MemSQL的聚合节点不缓存任何数据,但叶子节点会执行部分查询,以此减少发送到聚合节点的数据量。这在NuoDB中是不可能的,因为存储管理器只有数据存储功能,没有执行查询的能力。

这两个系统都能够向DBMS集群中添加执行资源(NuoDB的TE,MemSQL的聚合节点)而无需对数据库进行重新分区。SAP HANA的一个研究性的原型系统同样采用了这个方法。不过,从性能和操作复杂度方面,异构架构是否比同构架构(即所有的节点都可以同时执行查询和存储数据)更优秀仍有待进一步通过实践来检验。

NewSQL分区的一个新的功能是部分系统支持实时迁移。它们允许DBMS将数据在物理资源间进行迁移,以达到系统重新平衡,缓解热点压力,动态增加/减少DBMS容量的目的。这一点跟NoSQL系统的重新平衡类似,但是难点在于NewSQL DBMS需要在迁移中仍然维持ACID的事务特性。有两种方法能够做到这点。第一种方法是将数据库组织成为许多粗粒度的"虚拟"(即逻辑)分区,并分布到各个物理节点上。这样当DBMS需要重新平衡的时候,它可以将虚拟分区在节点间移动。Clustrix和AgilData使用了这种方法,NoSQL中的Cassandra和DynamoDB也使用了这种方法。另一种方法是DBMS通过范围分区重新分布单个元组或多个元组来执行更细粒度的重新平衡。 这类似于MongoDB NoSQL DBMS中的自动分片功能。 ScaleBase和H-Store等使用了这种方法。

4.3 并发控制

并发控制方案是事务处理DBMS中最突出和最重要的实现细节,因为它影响系统几乎所有的方面。并发控制允许最终用户通过多个程序访问数据库,而每个程序在都认为自己运行在专用数据库上。这一点非常重要,因为它提供了系统的原子性和隔离性保证,并由此影响了整个系统的行为。

除了系统并发控制方案外,分布式DBMS的设计的另一个重要方面是该系统使用集中式还是分散式事务协调协议。在集中式协调系统中,所有的事务操作都必须通过中央协调器,它负责决定事务是否得以执行。1970-1980年代的事务处理监控器(例如IBM的CICS,Oracle的Tuxedo)中采用了这种方法。而在分散式的协调系统中,每个节点维护访问其数据的事务的状态。节点之间相互协调来确定事务是否有冲突。分散式协调器具有更好的可扩展性,但为了产生和维护事务的全局顺序,DBMS的所有节点都需要与同一个高精度时钟保持同步。

1970-1980年代的第一代分布式DBMS系统使用了二阶段锁(two phase-locking,2PL)方案。SDD-1项目是第一个专用于由集中式协调器管理无共享节点集群中的分布式事务处理的DBMS。IBM的R类似于SDD-1,但是它的主要区别在于R系统的协调器是完全分散式的,它使用了分布式的2PL协议,这样事务可以锁定正在访问的节点中的数据项。INGRES的分布式版本中同样采用了分散的2PL和集中式的死锁监测。

几乎所有基于新架构的NewSQL系统都没有使用2PL,因为处理死锁问题的复杂度太高。当前的趋势是使用时间戳顺序并发控制的变体,其中DBMS假定那些违反串行顺序的事务不会执行交错的数据操作。在NewSQL系统中使用最广泛的协议是分散式的多版本并发控制(multi-version concurrency control, MVCC)。其中DBMS会在数据元组被事务更新时创建新的副本。维护多个版本的方案使事务即使是在其他事务同时更新相同数据时也能够成功地完成,也避免了长时间运行的只读事务阻塞写入操作。这个协议被多数基于新架构的NewSQL系统所采用,例如MemSQL, HyPer,HANA,CockroachDB等。虽然这些系统在实现MVCC的细节上使用了不同的工程方法进行优化,但是这个方案的基本概念并不是新的。MVCC最早是由在一篇MIT的博士论文中提出来的,第一个使用它的商业DBMS是1980年代Digital的VAX Rdb和InterBase。我们注意到InterBase的架构是由Jim Starkey设计的,他同时也是NuoDB最早的设计者,也是失败的Falcon MySQL存储引擎项目的设计者。

其他的系统使用了2PL和MVCC的组合方案。这种方案中事务仍然需要在2PL模式下请求锁来更新数据库,而同时当一个事务修改了一条记录时,DBMS也为这条记录创建一个副本。这个方案使只读查询可以避免请求锁,因此不会阻塞写事务。这个方法最著名的实现是MySQL的InnoDB。另外还有Google的Spanner,NuoDB,Clustrix也都用了这个方法。NuoDB改进了原始的MVCC,它使用gossip协议在节点间广播版本信息。

所有的中间件和DBaaS服务都继承了它们底层DBMS架构使用的并发控制方案,因为大部分都使用MySQL作为底层DBMS,所以大部分的都是使用的2PL加上MVCC方案。

我们认为Spanner(及其后代F1和SpannerSQL)中的并发控制实现是最新颖的NewSQL系统之一。实际方案本身是基于2PL和MVCC组合,但Spanner最大的不同是使用了硬件设备(例如GPS和原子时钟)来做高精度时钟同步,为事务分配时间戳,通过广域网络实施其多版本数据库的一致视图。CockroachDB声称会提供与Spanner一样的跨数据中心的事务一致性,但不使用原子钟。 它们依赖于混合时钟协议,该协议组合了松散同步的硬件时钟和逻辑计数器。

Spanner引人注目的另一个原因是它预示着Google将在最关键的服务中重新使用交易。 Spanner的作者甚至表示,最好让他们的程序员去处理由于过度使用事务造成的性能问题,而不是像NoSQL DBMS那样编写代码来处理事务的缺失。

最后,唯一没有使用MVCC及其变体的商业NewSQL DBMS是VoltDB。它仍在使用TO并发控制,不像MVCC那样交错执行事务,它通过调度使每个分区一次只有一个事务被执行。它还使用一种混合架构,其中单分区事务以分散方式调度,但多分区事务使用集中式协调器调度。VoltDB通过逻辑时间戳对事务进行排序,然后调度它们以便在轮到它们时在分区上执行。当事务在一个分区上执行时,它对该分区中的所有数据具有独占访问,因此系统不必在其数据结构上设置细粒度的锁和锁存器。因为没有来自其他事务的竞争,那些必须访问单个分区的事务得以有效地执行。基于分区的并发控制的缺点是,如果事务跨越多个分区,它不能很好地工作,因为网络通信延迟会导致节点在等待网络消息时处于空闲状态。这种基于分区的并发控制也不是新的想法。它的早期变体首先在1992年Hector Garcia-Molina的文章中提出,并在1990年代末在kdb系统和HStore(VoltDB的学术版本的前身)中得以实现。

综上,我们发现除了值得称道的工程方法使这些算法在现代硬件和分布式操作环境中更为高效外,NewSQL系统中的核心并发控制方案没有任何显著的新特点。

4.4 次级索引

次级索引包含来自表的不同于其主键的属性集。它允许DBMS支持主键和分区键以外的快速查询。当整个数据库位于单个节点上时,在非分区DBMS中支持它们是没有太多意义的。但是在分布式DBMS中,不会总是以正好需要的属性值进行分区。举例来说,假设数据库根据客户表的主键进行了分区。但是可能会有一些情况希望通过客户的email地址反向查询客户的账户。因为数据库是按照客户主键进行的分区,DBMS不得不将这个查询广播到所有节点,这明显效率非常低下。

在分布式DBMS中支持次级索引有两个设计决策:1)系统在哪里存储它们 2)如何由事务上下文维护他们。在使用集中式协调器的系统中,类似数据分片中间件,次级索引可以同时放在协调器节点和分片节点。这个方法的好处是整个系统中只有一个版本的索引,更加容易维护。

所有基于新架构的NewSQL 系统都是分散式的,使用的是分区的次级索引。意思是说每个节点存储了索引的一部分,而不是一个完整的副本。分区索引和复制完整索引之间的折衷是,前面的查询可能需要跨越多个节点来找到他们正在寻找的东西,但是如果事务更新索引,它将只需要修改一个节点。 在复制索引中,情况正好相反:查找查询可以仅由集群中的一个节点满足,但是任何时候事务修改次级索引关联的数据, DBMS必须执行一个分布式事务来更新索引所有副本。

Clustrix使用分散次级索引,将上述概念混合在一起。DBMS在每个节点上维护一个粗粒度(基于范围的)的索引的副本,而节点将索引值映射到分区。映射使用表分区属性之外的其他属性,这样DBMS可以利用映射关系将查询路由到适当的节点。因为次级索引将精确值映射到数据元组,于是查询通过索引就可以访问数据元组。这种两层的方法仅仅映射范围而不是单个的值,减少了保持索引副本在集群中同步所需的调度次数。

在使用不支持次级索引的NewSQL DBMS的过程中,开发人员创建次级索引最常见方法是使用内存中的分布式缓存(如Memcached)来部署索引。 但是使用外部系统需要应用程序来维护缓存,因为DBMS不会自动更新外部缓存。

4.5 复制

客户为其OLTP应用保证数据的高可用性和持久性的最好的方法是复制数据库。所有现代的DBMS,包括NewSQL系统,都支持某种机制的复制。DBaaS有一个突出的优势是它将所有复制配置的细节都对客户隐藏,因此部署一个DBMS的副本变得极为简单,用户无需关心日志是否传输成功,数据是否同步。

在数据复制中有两个设计决策。第一个是DBMS如何使数据保持节点间的一致性。在强一致的DBMS中,事务的写入必须在被确认提交(即持久化)之前被确认并被安装到所有副本。这种方法的好处是副本可以提供只读的查询并且仍保持一致性。也就是说,当应用收到了事务提交的确认,则该事务对数据库的任何修改对于后续所有的事务都是可见的,无论它们访问哪一个DBMS节点。同时,这样意味着如果一个副本失效,系统并不会丢失任何更新,因为其他所有的节点都是同步的。但是维护这样的同步需要DBMS使用原子提交协议(例如两阶段提交)来确保所有的副本与事务的执行结果一致,而这带来了额外的开销,并且如果节点失败或者有网络分区延迟则,也可能导致系统停滞。这就是为什么NoSQL系统选择弱一致性模型(也称为最终一致性),其中并非所有副本都必须在DBMS通知应用程序写入成功之前确认修改。

我们所知道的所有NewSQL都支持强一致性复制。但是在系统如何保证一致性方面并没有任何创新。在1970年代研究了DBMS的状态机复制的基本原理。NonStop SQL是在1980年代构建的第一代分布式DBMS之一,它就使用了相同的强一致性复制提供容错能力。

除了DBMS将更新传播到副本的策略之外,还有两种不同的执行模型用于决定DBMS如何执行此传播。第一种是主动-主动复制,其中每个节点同时处理相同的请求。例如,当事务执行查询时,DBMS在所有副本处并行执行该查询。这不同于主动-被动复制,首先在单个节点处理请求,然后DBMS将所得状态传送到其他副本。大多数NewSQL DBMS实现第二种方法,因为它们使用非确定性并发控制方案。这意味着它们不能向副本发送查询,因为它们可能在不同副本上以不同的顺序执行,并且数据库的状态将在每个副本处出现分歧。因为执行顺序取决于很多因素,包括网络延迟,缓存停滞,时钟偏差等。

另一方面,确定性DBMS(例如,H-Store,VoltDB,ClearDB)不执行这些附加的协调步骤。这是因为这些DBMS要保证事务的操作在每个副本上以相同的顺序执行,从而保证数据库的状态相同。VoltDB和ClearDB还确保应用程序不会执行那些使用外部信息源的查询,因为这些信息在每个副本上可能是不同的(例如,将时间戳字段设置为本地系统时钟)。

另一个NewSQL系统的独特之处是通过广域网WAN来进行复制。这是现代操作环境的副产品,因为现在很少在远距离的数据中心之间部署系统。所有的NewSQL DBMS都可以通过配置实现广域网上的同步复制,但是这也会引起正常操作中很明显的延迟,所以异步复制的方式更为流行。据我们所知,NewSQL系统中只有Spanner和CockroachDB能提供广域网上强一致副本的复制方案。Spanner使用了原子钟和GPS来做时间同步,而CockroachDB使用的是混合时钟方案。

4.6 崩溃恢复

NewSQL系统容错功能的一个重要特征是使用了崩溃恢复机制。传统的DBMS容错方案的重点是保障数据的更新不会丢失,而NewSQL DBMS除了这点以外,还希望最小化停机时间。现代的Web应用希望能够一直保持在线,因为停机带来的成本实在是太大了。

单节点无备份系统中恢复的传统方法是,在DBMS修复后重新联机,它将加载从磁盘取得的最后一个检查点,然后重播其写入日志(write-ahead log, WAL)以使数据库到达崩溃前那一刻的状态。这种方法的经典实现被称为ARIES,是IBM研究人员在1990年代发明的。 所有主流的DBMS都使用了ARIES的一些变体来实现故障恢复。

在有副本的分布式DBMS中,不能直接使用传统的单节点方法,因为当主节点崩溃时,系统将会自动提升某个从节点充当新的主节点,而之前崩溃的主节点重新联机后,因为DBMS已经有了新的数据,数据库并不停留在崩溃之前的状态,所以主节点不能直接从自己的检查点中恢复数据。恢复的节点需要从新的主节点或者其他副本中更新自己的数据,弥补在停机这段时间内缺失的数据。有两种方法来做这个事情:第一是恢复的节点仍然从自身的存储中加载最后的检查点和写入日志,然后从其他节点读取缺失的日志部分。如果这个节点处理日志的速度比数据更新快,节点上的数据最终会达到与其他节点上的副本相同的状态。如果DBMS使用物理日志,那么这种方法就是可行的,因为将日志更新直接应用到元组的时间远小于执行原始SQL语句所需的时间。另一种方法可以减少恢复的时间,即节点重新联机时丢弃其检查点,让系统给它另一个新的检查点,然后从这个点开始恢复。这种方法带来的一个额外的好处是,系统中加入新的副本节点时也可以用同样的机制。

中间件和DBaaS系统依靠底层单节点DBMS的内建机制来实现故障恢复,不过都增加了额外的主节点选择和其他管理能力。基于全新架构的NewSQL系统结合现成的组件(例如ZooKeeper, Raft)和他们实现的已有算法来做这类事情。所有这些都是自1990年代以来在商业分布式系统中可用的标准程序和技术。

未来趋势

我们预计,在不久的将来,数据库应用程序的下一个趋势是能够对新获取的数据执行分析查询和机器学习算法。这种通常也称为"实时分析"或者"混合事务分析处理(hybrid transaction-analytical processing,HTAP)"的应用通过分析新数据和历史数据的组合来进行知识推断,获得洞察力。比传统的商业智能只能基于历史数据进行操作要更为先进。对于现代应用来说,更短的周转时间非常重要,因为数据的价值在其创建时非常巨大,但随着时间推移逐渐减少。

在数据库应用里有三个方法支持HTAP。最为常见的一个方法是部署另一个DBMS,让其中一个专门处理事务,另一个处理分析查询。在这个架构下,前端的OLTP DBMS存储所有由事务创建的新数据,而在后端,系统使用抽取与转换(ETL,extract-transform-load)工具将数据从OLTP DBMS导入到另一个后台的数据仓库DBMS。应用在后端执行所有的复杂的OLAP查询,避免拖慢OLTP系统。所有在OLAP系统中产生的新数据也将会被推送到前端的DBMS中。

被称为λ架构的另一种主流系统设计是使用单独的批处理系统(例如,Hadoop,Spark)来计算历史数据视图,同时使用流处理系统(例如,Storm,Spark Streaming)来提供输入数据视图。在这个分离式的架构中,批处理系统周期性地对数据集进行重新扫描,并将结果批量上传到流处理系统,然后流处理系统将基于新的更新进行修改。

这两种方法都有一些固有的问题。最重要的一点是,在两个分离系统中进行数据传输的时间通常以分钟甚至小时来计算,而且在数据传输时应用程序不能进行数据处理。第二个问题是,部署和维护两种不同DBMS的管理开销巨大,因为人工成本占整个大规模数据库系统成本的的50%左右。

如果想要合并来自不同数据库的数据,还需要应用程序开发人员为多个系统编写查询语句。一些系统试图通过隐藏分离系统架构伪装成单个平台,例如Splice Machine,但是这种方法还有其他技术问题,因为在OLTP系统(Spark)中使用它之前,需要复制来自OLTP系统(Hbase)的数据。

第三个我们认为更好的方法是使用单个HTAP DBMS,它既支持OLTP工作负载的高吞吐量和低延迟需求,又允许在热数据(事务)和冷数据(历史数据)上运行复杂的长时间运行的OLAP查询。 这些较新的HTAP系统与传统的通用DBMS不同的是,它们结合了最近十年来在OLTP(例如,内存存储,无锁执行)和OLAP(例如,列式存储,矢量化执行 )领域的技术积累,而且只需要一个DBMS。

SAP HANA和MemSQL是最早的两个声称自己是HTAP系统的NewSQL DBMS。HAHA在内部使用多个执行引擎,一个用于更适合事务的行数据,另一个用于更适合于分析的列数据。MemSQL使用两个不同的存储管理器(一个管理行,一个管理列),但是混合在同一个执行引擎中。

HyPer原本使用H-Store风格的用于处理OLTP的并发控制。它切换到了带有MVCC的HTAP列存储体系结构,于是可以支持更复杂的OLAP查询。VoltDB甚至将他们的市场宣传策略从纯粹的OLTP性能转向提供流式语义。类似地还有S-Store项目,在H-Store架构之上增加了对流式处理操作的支持。始于2000年代中期的OLAP系统(例如,Greenplum)很可能将开始增强对OLTP的支持。

我们注意到HTAP DBMS的兴起意味着巨大的整体式OLAP数据仓库的衰落。这样的系统在短期内仍然是必要的,因为它们是所有前端OLTP应用孤岛通用的后端数据库。 但是最终数据库技术的发展将允许用户执行跨越多个OLTP数据库(甚至包括多个供应商)的分析查询,而不需要移动数据。

结论

我们分析的主要结果是,NewSQL数据库系统并不是与现有的系统架构完全不同的新物种,而是代表数据库技术不断发展的下一篇章。 这些系统使用的大多数技术已经存在于学术界和工业界的先前DBMS中很多年。但是以前这些技术只是独立地在某些系统中得到实现,因此NewSQL DBMS的创新之处在于它们将这些想法纳入了单一平台,而且人们付出了巨大的工程努力,作出了很多创新性的工作。虽然NewSQL DBMS是伴随着更廉价而丰富的计算资源出现的,但它们的应用范围和应用前景也因此而更为广泛。

同样有趣的是考虑NewSQL DBMS潜在的影响和未来的方向。鉴于传统的DBMS提供商的市场地位牢不可破,资金充足,NewSQL系统只能通过艰难的战斗赢得市场地位。在过去的五年中,一些NewSQL公司已经关闭(例如GenieDB,Xeround,Translattice)或者转向重点关注其他问题域(例如ScaleBase,ParElastic)。基于我们对一些公司的的分析和访谈,我们发现NewSQL系统的采用率相对较低,尤其是与开发人员驱动的NoSQL相比的时候。这是因为NewSQL DBMS的设计目标是支持事务性的工作负载,而这些应用大多数是企业应用。与Web应用相比企业应用对于数据库的选择更加保守。另外我们也发现NewSQL DBMS用于补充或者替换现有的RDBMS,但NoSQL通常用于新业务系统的开发。

2000左右OLAP DBMS刚刚兴起的时候,大部分开发商都被主要的技术公司收购。而NewSQL领域里目前还只有一家公司被收购。在2016年3月,Tableau宣布它收购了HyPer项目的初创公司。另外两个可能的例外是:

1)2015年3月苹果公司收购了FoundationDB,但是我们把它排除在外,因为这个系统底层是NoSQL的Key-Value存储,上面只有一层效率低下的SQL层;

2)ScaleArc收购了ScaleBase,但这起收购案发生在竞争对手之间。

这些案例中没有一个是传统巨头收购新兴公司的情况(例如2011年,Teradata收购Aster Data System)。反过来,我们看到巨头们更愿意在自己的系统上进行改进和创新,而不是去收购初创的NewSQL公司。2014年Microsoft在SQLServer上新增了内存Hekaton引擎来增强OLTP处理能力。Oracle和IBM的创新进度比较慢,他们最近才为系统添加了列存储扩展,与新兴的OLAP DMBS(例如HP Vertica和Amazon Redshift)展开竞争,并有可能在未来推出内存中的OLTP工作负载处理系统。

从更长期来看,我们将数据库的发展归纳为四类:

1)始于1980-1990年代的传统DBMS;

2)始于2000年代的OLAP数据仓库;

3)始于2000年代的NoSQL DBMS,

4)始于2010年代的NewSQL。

我们希望在这些分类中所有的核心系统将会支持某种形式的关系模型和SQL(即使它们还没有),并且会像HTAP DBMS一样同时支持OLTP操作和OLAP查询。当这一天到来时,这些标签将成为历史。

Posted by eygle at 5:28 PM | Permalink | IT新闻 (50)

April 22, 2019

尚若水之品,怀君子之德 - 北京东城区分司厅小学

东城区分司厅小学,2014年建校100周年,

校园内一棵300年历史的老槐树,见证了学校变迁的历史。

从最初的"京兆模范小学"到今天的"北京市东城区分司厅小学",

不管时代如何变迁,学校始终坚持以德立校,以德育人,传承这一中华传统文化的精髓从未改变。

校门口,10个大字彰显了学校的立人之期:"尚若水之品,怀君子之德",

而雕刻着"向真 向善 向美"的文化石则是对学生们的培养目标。

学校梳理了 "怀德立范,一树百获"的文化核心价值观,

确定了"培养向真、向善、向美的社会人"的育人目标。

Posted by eygle at 3:17 PM | Permalink | 人生百味 (19)

March 25, 2019

2019 Oracle的战略变化 和 Don Johson 的裁员邮件

在 Layoff 网站上,近期(2019-03-22)披露了一封 Don Johson 的邮件,其中阐述了Oracle战略的变化。Don 是Oracle的执行副总裁,带领 OCI 团队近万人的团队规模。这封邮件的信息可以一窥Oracle的变化。

原文链接:https://www.thelayoff.com/t/Ybg79FO

中文翻译:

团队,

我想与您分享今天发生的组织结构调整。

在过去几年中,随着Oracle逐渐发展成为云服务公司,我们已经看到了渐进式变革。这是整个公司的巨大转变,通常是我们的组织在其中心。它广泛而普遍地影响了整个业务 - 推动重组,重新调整投资,改变我们建立和运营服务的方式,以及发展我们与客户互动的方式。

在去年的Oracle Open World大会中,Larry明确了公司的愿景和方向:我们是一家企业云公司,为最严苛的客户需求和最具挑战性的工作负载提供支持。我们围绕两个重心重构组织:应用和基础设施。作为我们云计算业务的基础,OCI - Oracle的第2代云 - 为我们的客户提供安全,可靠的基础架构平台,支持我们业务,自治数据库和SaaS ERP。

公司的一切都围绕着这个清晰的愿景和方向。

今天OCI内部的变化将更好地与Larry的业务愿景保持一致。它将简化我们的产品和服务,将投资重点放在我们最具战略意义的优先事项上,并帮助我们更有效,更快地实现Oracle Gen 2 Cloud的全部承诺和覆盖范围。

请于3月22日星期日上午10点,也就是明天上午10点,参加OCI领导和我的全体会议,以获得有关这对我们的团队和业务意味着什么的更多信息。

OCI的业务比以往任何时候都更加强大,这个团队的未来是光明的。我要感谢大家的继续支持,因为我们加倍了解我们的战略要求。我们将建立区域,继续招聘和投资战略领域,并快速发展业务和客户。

--Don

英文原文:

Team,

I wanted to share with you context for the organizational restructuring happening today.

Over the past several years we've seen progressive change as Oracle has evolved into a cloud services company at its core. This is a giant shift across the company, often with our organization at its epicenter. It has affected the entire business broadly and pervasively - driving reorganizations, realigning investments, changing how we build and operate services, and evolving how we engage with our customers.

At last year's Oracle Open World, Larry was clear about the vision and direction of the company: We're an enterprise cloud company supporting the most demanding customers and the most challenging workloads. We're organized around two centers of gravity: Apps and Infrastructure. As the foundation of our cloud business, OCI - Oracle's Gen 2 Cloud - provides our customers with a secure, reliable infrastructure platform that supports the primary pillars of our business, Autonomous Database and SaaS ERP.

Everything in the company is aligning around this clear vision and direction.

Today's changes within OCI will better align with Larry's vision of the business. It will streamline our products and services, focus investments on our most strategic priorities, and help us to more effectively and rapidly deliver the full promise and reach of Oracle's Gen 2 Cloud.

Please join the OCI Leadership and me in an All Hands tomorrow, March 22nd, at 10:00 AM PDT to get more information about what this means for our team and the business.

OCI's business is stronger than ever, and this team's future is bright. I want to thank you all for your continued support as we double down on our strategic imperatives. We'll be building regions, continuing to hire and invest in strategic areas, and growing the business and our customers at a rapid pace.

--Don

以上信息仅供参考。

Posted by eygle at 1:57 PM | Permalink | IT新闻 (50)

2019年Oracle 大举裁减工程师团队,或涉及上万人

转引网络新闻:http://www.sohu.com/a/303383806_465914

本周Oracle效仿IBM的做法,实行未对外宣布的裁员,期望通过重组并向云计算转型来优化公司,对裁员一事几乎没有承认。

昨天Oracle挥起了裁员利斧。这家公司并没有透露确切的裁员人数和具体岗位,不过裁员规模显然很大。墨西哥裁员50人,新罕布什尔州裁员50人,印度裁员100人,硅谷也至少裁员100人――据theLayoff.com上的传闻报道和内部风声,裁员人数很快积少成多。这个网站为受裁员影响的人员开设了讨论区。

传闻满天飞,不过全球裁员数量似乎多达数千人。theLayoff.com上的一则匿名帖子似乎给出了实际的数字,表明裁员目标总数占Oracle全球员工总数的10%,2018年员工总数约137000人。发帖人表示,今年将分三个阶段裁员,第一个阶段约5000名员工将被裁。

裁员对Oracle来说根本就不是什么新鲜事;2017年,该公司在硅谷裁员近1000人,主要来自SPARC团队和Solaris团队。但这次裁员行动的突然性和隐秘性,还是让员工和观察人士大跌眼镜。这次裁员不但缺乏透明度,还很突然,这让人想起了IBM过去的裁员潮。

Oracle的裁员日始于太平洋夏令时上午5点,当时Oracle执行副总裁Don Johnson发送了一封标题为"组织重组"的电子邮件,发到了员工的收件箱。该邮件告知工作人员:将来,公司的一切工作都将围绕Oracle云基础设施(OCI)业务展开。

Johnson写道:"今天OCI内部的变化与拉里•埃利森的公司愿景更保持一致。它将简化我们的产品和服务,将投资重心放在我们最具战略意义的优先事项上,并帮助我们更高效、更快速地兑现Oracle第二代云的全部承诺和覆盖范围。"

该邮件随后的一句话让员工大为光火:"OCI的业务比以往任何时候都更强大,该团队的未来一片光明。"

据悉,大概上午10点左右,离邮件发送过去才5小时,裁员就开始了。据传闻报道,大规模裁员牵涉这个比以往任何时候都更强大、未来一片光明的云业务的至少一部分人。那些受影响的员工有30分钟的时间交出公司资产、离开大楼,并被告知周五是他们在公司的最后一天。

一名Oracle员工称:"这天早上感觉就像是一场屠杀。一个接一个。影响我的人走了,帮助我取得成功的人走了,优秀聪明能干的人都走了。这是糟糕的一天。一家公司最宝贵的资产莫过于它雇用的人员。今天的大裁员让我很想知道Oracle是否会意识到裁掉这些人犯了多大的错误。"

该员工还说,裁员过程的处理方式非常糟糕,整支整支的团队被集体叫到会议室,告知他们被统统解雇。该员工表示,技术团队受到的打击似乎最大,尤其是参与产品开发的团队,以及专注于软件开发、数据科学和工程技术的团队。

并不是只有这名员工觉得本周的裁员过程特别残酷。

theLayoff.com上的一位匿名发帖人写道:"刚接到一位朋友的电话,说他就解雇了。最令他烦恼的是,告知裁员消息的是一名不是他直属上司,之前也从来谈过话的高管。"

一位Oracle经理发帖到:"前一天我接到通知,称公司要开除名单上的一位员工,随后人力资源部门强行要求我在通告会上向他宣读最无情的裁员声明。我听说其他经理连手下员工被开除的通知都没有接到,他们在员工联系自己后才获悉裁员。更为糟糕的是,那些不得不通知下属裁员的经理一小时后自己也被解雇了。昨天对某些部门来说就是一场不折不扣的血洗,Oracle的处理方式极不厚道。"

被要求发表评论时,Oracle只给出了下列准备好的声明:"随着我们的云业务不断发展,我们将不断调整资源,并重组我们的开发团队,以帮助确保我们有合适的人员为全球各地的客户提供最佳的云产品。"

Posted by eygle at 1:36 PM | Permalink | IT新闻 (50)

近期发表

  • 2016年中国数据库市场销售规模超过100亿元 - March 25, 2019
  • Oracle跟踪和诊断的利器: ORADEBUG 手册 - September 30, 2018
  • Percona最新发布XtraBackup for MySQL 8.0 - September 13, 2018
  • 对话李飞飞:在谷歌听得见炮火 回斯坦福看下个方向 - September 12, 2018
  • 数据库流行度排行榜 - September 3, 2018
  • 解析 vcard规范 二维码名片的格式 - September 3, 2018
  • Jonathan Lewis:我很为DBA们的未来担心(图灵访谈) - November 26, 2013
  • 吕海波(Vage)- 突然35岁:捡点我的职业生涯 - July 31, 2013
  • 吕海波(Vage)- 漂泊的技术人生 - ITPUB访谈录 - July 31, 2013
  • Oracle群英录 - 2013上海OOW名人录 - July 26, 2013


  • CopyRight © 2004 ~ 2012 eygle.com, All rights reserved.