eygle.com   eygle.com
eygle.com eygle
eygle.com  
 
Digest Net: IT新闻 Archives

Recently in IT新闻 Category

原作者: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查询。当这一天到来时,这些标签将成为历史。

在 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

以上信息仅供参考。

转引网络新闻: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只给出了下列准备好的声明:"随着我们的云业务不断发展,我们将不断调整资源,并重组我们的开发团队,以帮助确保我们有合适的人员为全球各地的客户提供最佳的云产品。"

:关于中国数据库市场的容量和规模,数据总是较难获得,以下是转引的一则报道,其中数据可以作为一个概要参考。帮助读者了解中国数据库市场的情况。

原文链接: http://www.chyxx.com/industry/201708/553364.html

我国数据库技术亦如计算机技术的发展,起步较晚,大约始于七十年代中期。1977年11月,由中国科技大学在黄山主办了第一次数据库技术研讨会,标志着中国数据库软件产业进入了技术跟踪期,其后经历了三十多年的发展,中国数据库软件产业相继经历了强势垄断期、创新发展期,最终进入了目前的产品成熟期。

20170823141752_m.png

数据库软件是一种非常重要的基础软件,是我国信息化建设中需求量最大、应用最广泛的软件之一。国产数据库软件经过多年发展,已成功应用于政府、军队、教育、电力、金融、农业、卫生、交通、科技等行业和领域,为国家信息安全和国民经济信息化作出了巨大贡献。

近年来,随着我国信息化的深入发展,数据库软件市场规模快速增长,国产数据库软件也迅速崛起。 智研咨询发布的《2017-2023年中国数据库市场深度分析及未来发展前景预测报告》指出:2015年我国数据库软件市场规模为85.37亿元,2016年我国数据量软件市场规模增长至101.45亿元

20170823141812_m.png

2016年我国国内主要数据库企业:

  • 南大通用销售收入为2.35亿元,占同期国内数据库市场规模总量的2.3%;
  • 山东瀚高销售收入为0.58亿元,市场份额为0.6%;
  • 爱可生销售收入为0.76亿元,占比为0.7%;
  • 2015年人大金仓销售收入为0.59亿元,2016年销售收入在0.65亿元左右。

20170823141813_m.png

我国引入数据库始于20 世纪70年代,2016年我国数据库软件市场规模为101.45亿元,Oracle 数据库占比超过40%,

国产数据库软件主要有人大金仓、武汉达梦、神舟通用、南大通用、山东瀚高等,其中南大通用市场份额为2.3%。

2017082314181339_m.png

云时代下,我国数据库产业,特别是DBaaS 产业受益两大因素迎来黄金机遇期:

(1)政策鼓励云计算发展;

(2)去IOE 和分布式改造背景下,银行、电力等部门数据库国产化需求强烈。

Percona最新发布XtraBackup for MySQL 8.0

原文链接:http://www.enmotech.com/web/detail/1/593/1.html

相关文章链接:http://www.enmotech.com/web/detail/1/577/1.html

更多精彩请关注"数据和云"公众号

我们的产品:http://www.enmotech.com/services/software.html

zData 一体机:http://enmotech.com/web/classify/26.html

Bethune(白求恩)https://bethune.enmotech.com/

SQMhttp://www.enmotech.com/web/classify/25.html

ZONEhttp://www.enmotech.com/web/classify/28.html

在下文所有的废话之前,先说正事:

Percona在9月12日,终于宣布第一个测试用的XtraBackup for MySQL 8.0版本给大家试用:

(复制链接打开)https://www.percona.com/blog/2018/09/12/announcement-experimental-build-of-percona-xtrabackup-8-0/

MySQL 8.0今年4月份GA以来,虽然大家多有测试,但实际上敢用到生产环境的,只是极少数.而我个人认为最重要的原因之一,就是缺乏一个可用的备份工具.而在MySQL备份这件事情上,功德无量的Percona公司,却迟迟没有见到发布针对MySQL 8.0的备份工具,着实让人着急.

在9月12日之前,已知的MySQL 8.0的备份方式有这些:

  1. 官方MySQL商业版备份工具. 这个名为 MySQL Enterprise Backup 的软件,是官方商业版本的一部分,如果需要用,得掏钱买授权.先不说用的人比较少,使用文档本身也不在 MySQL 的公开文档导致学都很繁琐,就只是照着实例数收钱这点,就断绝了现在这种千库万表的 MySQL 大规模部署形势下的使用.

  2. 使用mysqldump命令.mysqldump 本身只是导出数据的命令行工具,但结合事务选项,以及master data选项,就可以导出满足一致性的备份SQL文件,即原生,又省心省力,对于小型数据库来说,是非常不错的选择(这里的小型,一般指的是100GB以下的数据库),但对于非常大个头的数据库来说,一来mysqldump是单线程导出,速度比较慢,说不定得搞一天,又由于MySQL的事务可见性的要求,undo文件会被执行导出的事务一直拖着不让缩小(如果没有使用独立表空间,那问题就更严重了-ibdata1过大的问题早年困扰不知多少DBA),导致磁盘空间比较大.而另外一个比较少遇到,但遇到就非常心碎的问题是,由于导出的是单个文本文件,如果文本文件中,某一个字节的存储出现问题,那么整个数据库的恢复就到此为止了.

  3. FLUSH TABLES WITH READ LOCK;见过很多以为备份数据库就是把数据文件直接复制走的哥们,如果他们在复制文件前,使用命令停掉所有的写入,之后再复制,也不能说人家有问题,奈何大部分人就是少这一步,而且,考虑到8.0开始,授权表都是innodb了,如果不小心,导致授权表损坏了,那可真是苦都没地方哭了.

  4. 考虑到很多人的备份不追求事务一致性,但速度要快,这种情况下,还有两个工具可以用,一个是mysql自带的mysqlpump,和 mysqldump 不同,mysqlpump支持表级别的并行导出,加快了导出速度,但放弃了事务的一致性要求.而mydumper则是早年,社区开发的一款并行导出MySQL数据的命令行工具,可以在一个表上,发起多个基于主键(或者唯一键)分区的并行导出,速度更快.

  5. 备份是为了恢复,恢复就要讲究恢复时间,那怎么样加快数据的恢复时间呢?那就是MySQL复制给出的答案: 建立一个开启了延迟备份的从库,在需要恢复数据到指定时间点的时候,直接用start slave until命令搞定. 注:个人建议是,对重要数据库,以及超大数据库(比如1TB以上的),都使用这种方式,来降低恢复时间,参考官方文档:(复制链接打开) https://dev.mysql.com/doc/refman/8.0/en/replication-delayed.html

  6. 既然说起从库,那么在从库上,就可以很方便地搞备份了,比如搞一个没有业务访问的从库,需要备份的时候,停掉slave(政治正确的叫法是replication)线程,然后用前面提到的方式3,4进行备份,也不是不可以,或者说,考虑到主库需要承担访问压力,这种备份方式从效率和一致性,以及对线上业务扰动综合看,实际上是非常好的一个方式.

  7. 数据文件存在磁盘上,既然方式3可以用cp命令拷贝,实际上就是允许使用所有文件系统/块设备/存储设备的快照备份了,只要记得执行前后FLUSH TABLES WITH READ LOCK;,那备份就有保障了.

我故意漏掉了myisam这过时玩意的备份恢复的手段,估计没人看也应该没人用,就不写了.

在前面列举的种种备份中,最理想的,实际上就是MySQL Enterprise Backup这种,所谓真正的热备份,在备份效率,与备份的一致性,安全性等方面,都是非常好的选择,开源世界中,对应的就是 XtraBackup.

这里也不多说XtraBackup本身的意义与使用方式,估计用MySQL的DBA,没有几个没有折腾过这玩意的,下文主要讨论的,还是Xtrabackup for MySQL 8.0.

首先看看Percona公司自己的说法(以下为作者提取的重点,原文参考前面的链接地址):

  1. 虽然已经发布了,但版本号是 8.0.1,并且提示为实验性质的(experimental)alpha版本.

  2. innobackupex命令终于被彻底删除,宣告一个时代的正式落幕,当然,也宣告着,很多MySQL自动化备份脚本需要改了.

  3. 由于MySQL 8.0数据目录,以及redo格式的种种变化,新的Xtrabackup for MySQL 8.0,仅仅提供给MySQL 8.0(以及Percona自己基于MySQL 8.0改的Percona Server),对于5.x版本,依然需要使用XtraBackup 2.4来备份,当然,也宣告着,很多MySQL自动化备份脚本需要改的地方更多了.

  4. 目前提供支持的操作系统版本为(其中Ubuntu 14.04 Trusty以及Debian 8 Jessie后续可能不再支持):

  • RHEL/Centos 6.x

  • RHEL/Centos 7.x

  • Ubuntu 14.04 Trusty*

  • Ubuntu 16.04 Xenial

  • Ubuntu 18.04 Bionic

  • Debian 8 Jessie*

  • Debian 9 Stretch

5. 如果需要下载,需要从Percona的repo源中下载,没有单独的下载地址(打算从官方软件下载页面找进去的同志可以放弃了):

centos 7 http://repo.percona.com/experimental/7/RPMS/x86_64/percona-xtrabackup-80-8.0.1-1.alpha.el7.x86_64.rpm

centos 6 http://repo.percona.com/experimental/6/RPMS/x86_64/percona-xtrabackup-80-8.0.1-1.alpha.el6.x86_64.rpm

至于其他发行版的同志,可以参考 https://www.percona.com/doc/percona-repo-config/index.html 这个地址的方法进行设置并下载

使用方法还是没有变化,想要试一把的同志,可以开搞了.

原创:刘伟。

投稿:有投稿意向技术人请在公众号对话框留言。

转载:意向文章下方留言。

更多精彩请关注 "数据和云" 公众号 。

招聘专栏

云和恩墨(北京)信息技术有限公司

Oracle 售前工程师(广州、深圳、上海、武汉、北京、石家庄)

Oracle 高级工程师(上海、深圳、北京、成都、昆明、贵州、西宁)

MySQL 技术经理(上海、南京、成都)

MySQL 工程师(上海、杭州)

超高待遇:丰厚的年终奖,五险一金,高额学习基金,团建旅游,法定节假日,福利假期等。

推荐他人成功入职有好礼(iPhone X)相送 。

投递简历至邮箱:hr@enmotech.com

末4.png

Pages

Powered by Movable Type 6.3.2

About this Archive

This page is an archive of recent entries in the IT新闻 category.

Oracle摘 is the next category.

回到 首页 查看最近文章或者查看所有归档文章.