精华内容
下载资源
问答
  • 本次讲座将分享华东师范大学数据库团队近期的一些科研思路和研究成果。首先分析驱动数据库技术发展的主要因素,谈一谈未来有价值的研究方向。再聊一聊团队近来取得的一些有趣的研究成果,领域包括新硬件的数据库适配...

     

    【Top Talk/大咖说】由美团技术学院和科研合作部主办,面向全体技术同学,定期邀请美团资深技术专家、业界大咖、高校学者及畅销书作者,为大家分享最佳实践、互联网热门话题、学术界前沿技术进展等内容,帮助美团同学开拓视野、提升认知。

    2020年10月27日,Top Talk邀请到了华东师范大学周烜老师,请他带来题为《华东师范大学的数据库系统研究》的分享。本文系周烜老师分享报告的文字版,希望能对大家有所帮助或者启发。

    /报告嘉宾/

    周烜 | 华东师范大学教授,数据科学与工程学院副院长

    2001年本科毕业于复旦大学,2005年在新加坡国立大学取得博士学位,2005年至2010年期间先后在德国L3S研究中心和澳大利亚联邦科工组织从事科研工作,随后在中国人民大学信息学院任教6年,于2017年3月加入华东师范大学。研究兴趣包括数据库系统和信息检索技术。曾参与和负责多个国内外的科研项目和工业合作项目,积累了丰富的数据管理系统研发经验。研究成果被发表于众多国际一流的学术会议和期刊。凭借在分布式数据库领域的成果转化获得国家科技进步二等奖和教育部科技进步一等奖。入选教育部“新世纪优秀人才”支持计划。

    /报告摘要/

    华东师范大学是国内为数不多长期坚持数据库内核技术研究的高校,在学术界和工业界均建立了较好的声誉。本次讲座将分享华东师范大学数据库团队近期的一些科研思路和研究成果。首先分析驱动数据库技术发展的主要因素,谈一谈未来有价值的研究方向。再聊一聊团队近来取得的一些有趣的研究成果,领域包括新硬件的数据库适配、分布式事务处理、HTAP、系统实现模块化(Modularization)等等。

    00 引言

                 

    今天我代表华东师范大学的数据库团队,来分享一下对数据库这种技术或者这种产品的一些研究心得以及当前的研究成果。其实,高校跟企业实际上是处在两个不同的生态领域当中,高校更关注关于研究理论的一些问题,但是企业更多的关注企业本身的产品以及用户,所以两者面向的目标是不太一样的。但是经过我们在华师大这么多年的一些摸索,特别是我们自己研究上的一些摸索,以及跟企业合作的经历,我们觉得实际上高校和企业应该一起来做我们称为数据库系统或者基础软件的研究,因为只有这样才能够更好的推动这个行业本身的发展。

    我的报告内容会分成两个部分。首先分享一下我们对数据库这种技术发展动态的看法,我们团队在数据库这个领域也做了很多年,包括我之前在中国人民大学也是做数据库系统的,我在这个领域里面有可能不到20年的积累。我希望能够提出我们的看法,并且能够得到大家的一些反馈,纯粹是做一种探讨,因为对技术的发展方向的探索,没有标准的答案。我觉得大家应该集思广益,共同去探讨,才能把这个问题看得更清楚,这是讲座前面一部分的内容。

    后面一部分的内容我会聚焦到我们的一些研究成果上,这些研究成果可能就会比较技术细节了,会更适合搞技术、数据库、系统的这些同学,但是我会尽量把讲座的形式变得更大众化一点,尽量用更通俗的方式去给大家介绍。我希望通过这种细节的介绍,也能够让大家了解一下,我们在设计系统的时候,通常一个工程师、一个研究者或者一个学者,他的思路大概是怎么样的,我不能代表所有的人,但是因为我们这个团队是一个典型的做系统的团队,所以这个思路可能仅代表了一部分做系统的学者的思路。

     

    01 数据库系统的形态变化

     

    1.1 什么引起了数据库系统的形态变化?

    首先问大家一个问题,什么引起了数据库系统的形态变化?我们知道数据库系统实际上是一个有很长历史的系统,是现代软件开发的一个核心部件。任何应用都离不开某种数据库,但是我们其实也可以看到,如果你有一定的经验,比如大概10年的工作经验,你会看到数据库系统的形态是在发生变化的,10年前用的很流行的东西,现在不见得普遍被采用。这个系统虽然有很长很长的历史,也很成熟了,但是它的形态还是在发生变化的。

    什么在驱动数据库系统的形态变化?这是一个很重要的问题,也是比较有趣的问题,但并不是一个好回答或者能够全面的回答的问题。我这里就直接抛出我们对这个问题的一些看法,我们觉得数据库系统的形态变化,主要来自三个方面的推动力:

    • 第一个方面是应用需求的变化。我们的软件产品一直在变得越来越丰富,应对的场景越来越多,实际上应用需求是在变化的,它的变化提出了不同的要求需求,它在促使数据库系统的形态在发生改变。

    • 第二个方面在学术界其实比较少去触及的,就是软件开发模式的变化。数据库是70年代80年代设计的,面对的是当时的软件开发模式,我们知道在九十年代以后,软件开发模式实际上发生了很大的改变。软件开发的模式的变化,也在引起数据库使用方式的改变,也在推进数据库系统的演变。

    • 第三个方面就是硬件平台的革新,硬件在改变处理器、存储器件,整个平台以前是一个大型的计算机,大型机、中型机,然后现在其实就是云平台,这些东西的变化实际上是在影响数据库本身的形态的改变。

    我们看到的推动力主要就是这三个。我们认为未来推动数据库变化的原因也不出于这三个,我们可以通过这个东西去预知未来应该朝什么方面去推进我们的数据库技术的进步。下面我就大概做一个简单的展开。

     

     

    1.1.1 应用需求的变化

    首先第一点就是应用需求的变化。我们认为这实际上是在推动底层技术,像数据库系统这种技术变化的一个主要原因。

                 

    通过上面这三幅图大家能够很容易去理解数据库诞生的年代,那个时候磁盘作为一个存储介质,刚刚在市场上推广,磁盘取代了磁带,数据的随机访问变的可能了。那个时候对数据管理功能的需求一下子就增长了,当时出现了各种各样的数据库,包括网状数据库,包括后面的关系数据库,那个时候是我们叫前互联网时代就出来了。但那个时候应用的规模并不大,数据库的用户量一般,终端用户其实很少,对于一个银行来讲就是那些银行职员在使用数据库,普通用户在银行排队,他们不是终端的使用者。

    后来进入到互联网时代之后,我们发现终端的使用者一下子就爆炸性的增长了。现在我们每个人有一个手机,随时都在使用手机上的App,然后这个App他随时都会把请求发送给后台的数据库。我们看到应用规模在最近20年有一个很大的增长,如果往后看的话,未来我们认为增长有可能还会继续。我们的工业互联网、物联网使用的话,我们的终端会变得更多,他可能对数据管理系统的压力会变得更大。

    所以我们看到应用不断的扩张,给数据库这种底层系统有一个持续增长的压力,要应对这样的压力,以前对数据库的设计,它逐渐就变得不太实用,必须去革新,必须去改变它。

    这个是我们看到的一个最主要的推动力。但除了应用规模的扩展,当然就还有一个应用领域的扩展,最开始的数据库它就是金融领域或者电信领域去使用,并不会在互联网、销售或者传媒等等这些领域去大规模的使用,但是我们发现IT的渗透到各行各业之后,它的应用范围也在增加,应用范围增加对传统的系统来讲是不友好的,或者是说你的传统数据库系统对这些应用是不友好的,所以这个也在推动它的一个变革。

                 

    应用需求带来什么变化?我们回顾历史的话,我们看到分布式数据库现在变得越来越被大家所需要,大家看到了谷歌的一些分布式数据库的产品,它现在作为一种标杆的产品,然后国内也有一些分布式数据库的场景,包括美团在内,听说美团内部也在研制自己的分布式数据库,实际上是在对需求的负载增加的一个应对。

    应对它实际上并不是一个很简单的事情,如果要增加你的数据库的扩展性,有时候你必须要重新去设计你的数据库的架构。我们通常做系统的同学应该了解,其实在做系统的时候,你需要做很多折中的考量的,有些东西是不能兼顾的,比如说你的功能性和应用性对吧?一个东西特别简单去使用的话,它功能性有时候就是比较简单,它复杂的功能处理不了,或者是你的功能很复杂的时候,你的扩展性又上不去。

    在系统设计的时候你必须去做一种权衡,去获得一部分这方面的能力,你就必须丢失其他的一些能力。当你需要它的扩展性非常强的时候,你有可能就要去重新考量它,你要去丢弃什么东西,你要去忍受什么其他的一些东西,然后这个时候就产生架构的变化,这样的话我们就会发现有新的系统出来,比如说以前的是SQL,我们现在有讲NoSQL大家认为它的扩展性容易做的更好一些,然后会有其他形态的一些数据管理产品。

    针对这个问题,学界工业界都有很多的讨论,Michael Stonebrake大概10多年前发表的一些言论,就说“One size does not fit all”,你不太能指望某一个系统能够能够处理所有的应用需求。因为不同的应用需求,你可能必须要做不同的折中、重新的考量,你只能顾此,你顾此只能失彼,所以这样就产生了一个多样化的形态。

    我们现在看到的数据库,如果你们在使用的话,你会面临很多选择,你到底用MySQL还是MongoDB对吧?你的分析的时候你要用什么?用Hadoop还是用传统的数仓MPP产品,有不同的需求,可能有不同的考量。这个我们看到应用需求它的变化,它的增加,它在实际上对这个系统起到了一个很重要的推动的这个作用,这是我展开的第一点。

     

    1.1.2 软件开发模式的转变

                 

    然后,第二点就是我们发现软件开发模式的变化,也在促进数据库本身的改变。就像我刚才提到的,现在用到的很多软件开发的模式跟以前不一样。以前关系数据库这样的产品刚刚被广泛应用的时候,当时的软件开发它是以数据为中心的,一个数据库设计出来,有好多应用都会去用它,它是一个Shared底层系统。那个时候数据库的设计过程,它是相对独立的,DBA根据App开发人员的需求、用户的需求,以DBA的方式去设计数据库,按照对数据模型的理解,把它设计得非常的规整,要满足各种各样的范式,然后给不同的应用去用。但现在我们发现一旦用到微服务这种新的开发模式的时候,很多时候这种横向的分割变得不是那么重要了。原本数据是一层、应用逻辑是一层,这两层之间的解耦是很重要的,但现在不是了。

    现在是微服务的形式,是纵向的切割,把业务整个分成一块一块的,每一块里面都有单独的数据库,有单独的功能设计,这弱化了数据库跟应用之间的界限,强化了应用里面不同模块的界限。这样的话,每个模块可以用不同的数据库产品,比如说一个设备用MySQL,另外一个设备可能用MongoDB,第三个设备可能用ES,这些模块之间的数据有同步有交互,可以用一些比如像事件驱动的架构,像Kafka这种MQ (Message Queue)去连接在一起,形成一个总体的架构。

                 

    这种设计跟以前的数据库是不太一样的,对于数据库本身的要求也不太一样。不同的Service会用不同形态的数据库产品,根据需求或者根据软件开发者的习惯,去采用各种缓存、消息队列等,去把这些东西给嫁接在一起。这样的形态对数据库有不同的要求,所以NoSQL被很多人接受。

    在某些软件开发的场景下,NoSQL就是比关系数据库使用起来更简单。然后事务的处理方式也变得很不一样,现在的消息队列在事务处理中,它的权重非常的高,而不是完全依赖于传统数据库内部支持事务处理的模式。这个是我们也看到这样的一些变化,这个是软件开发模式带来的一些改变。

     

    1.1.3 硬件平台的革新

                 

    第三个方面就是平台的革新。其实我们不会对传统的数据库的硬件平台灵活性有太多的关注,但现在数据库产品面向的基本上都是云平台,不是以前的IBM大型机了,不是Oracle那个时候的硬件平台。我们面对的是一个云平台,云平台自身是在发展的。以后的云平台其实可以预见得到,它不单单是现在我们看到的,是由一个个虚拟机或者是一个个容器组成的一个计算平台,还有可能就像一个大型的计算机一样,只是这种大型计算机它的资源非常的丰富,需要调用什么样的资源都可以获得,需要更多的内存、CPU、存储,都可以直接的获取。

    云平台通过比较高效的网络方式把这些资源全部连在一起,然后给用户的接口也很简单,很多维护功能是在云平台内部去实现的。数据库要扎根在这样的一个云平台上面,其实对数据库系统就会有新的要求。以前的数据库,大家都记得有几种架构可以选择,叫Shared Everything、Shared Nothing、Shared Disk这样的一些架构。

    但是我觉得在“云”层面上,数据库其实不再是那么简单去划分的,就是说数据库系统的产品,必须要做到具有很好的弹性。任何的资源在短缺的时候,可以通过云的这种方式很快的把资源调度过来,从而增加数据库的能力。对用户的话,只是提供一种数据库的服务,用户用多少?就提供多少。这样的一个云架构下的数据库,形态可能跟以前要有一些变化。除了这种云的体系之外,其实还有一些新硬件出现,硬件种类也变得越来越多。不同的种类的硬件,在不同的条件下,算力也在不断增加。当然除了计算,还有存储也发生很多变化,把这些放到云的里面去,云的资源变得更加丰富,对数据库的要求也会变得更高。

    因此,我们看到这种硬件平台的变革,它实际上在推动数据库的一些发展。现在大家很常见的就是这种计算与存储分离的这种架构的数据库。我把数据库本身这种系统,它的计算层跟存储层完全的分割开,计算层可以自己扩展,存储层也可以自己扩展,两层就通过云这种高速的、互联的通道能够连接在一起,这种实际上就是针对云的一个特殊的处理。我们知道存储是便宜的,所以在存储需要扩展的时候,没有必要在扩展存储的基础上去加CPU的资源,因为CPU比较贵。如果分开扩展的话,这样确实会在成本上有极大的提升。

    未来各种资源加进去之后,它都有可能有扩展的需求。比如说缓存,新的存储器,新的内存加进去之后,有可能需要它跟底层的存储分开,进行一个隔离,再分别去扩展,这都是有可能的。但现在的数据库产品其实面对这种扩展能力,实际上是非常有限的,存储和计算分开扩展到一定程度,实际上它的能力就达到一个峰值了。那么怎样去推动它进一步的这种弹性的增加,实际上是一个挺难的问题,但是也是挺有趣的问题。

                 

    新硬件对数据库产品的影响,这里有一个简单的公式,公式的左边叫做Data/Cost,单位数据处理,单位代价上面可以处理多少数据。这个是我们需要提升的,因为可以想象以后的数据量会越来越大,如果不把单位价格上面能处理的数据这个值提升的话,应对数据的能力就没办法提升。数据越多,需要花费的资源或者代价就越多,这个是我们不希望看到的。希望左边这个式子中Data/Cost的值随着技术的进步,它可以逐渐的提升。

    然后把左边这个式子它分解一下,分解成Data/Hardware和Hardware/Cost的一个乘积。这其实是很简单的一个因素分解,大家能够看得很明白。我们发现后面这个式子Hardware/Cost,实际上它的增长在逐渐的趋缓甚至停滞,主要的一个问题就是单位价格能够买到的硬件资源,要在这上面做更进一步的提升,会变得非常的困难。

    最后,如果想实现Data/Cost的提升的话,只能去提升左边这个式子Data/Hardware,这个是未来一个很明显的趋势。怎么样能够提升Data/Hardware?就是单位硬件下处理数据的能力要怎样提升?我们认为只有两种途径,第一种是硬件定制化,面对不同的应用需求,需要为这种应用需求做特殊的硬件。其实我们能看到像GPU、TPU这种出现,其实就已经在揭示这种规律了,专用硬件效率总是要比通用硬件好的。然后软件是一样的,专用的软件的效率肯定比通用的软件好。

    这个趋势我觉得可以从长期来看,短期可能并不是那么的明显,但长期来看的话,这个过程应该是不可阻挡的,也就是说我们可能会面临要去为应用去定制系统,要为专门的这种系统配置适合它的硬件。

     

    1.2 数据库系统的未来发展趋势

                 

    我们刚才讲了三点,第一点就是应用的变化在推动系统的演进;第二个是软件开发模式的变化实际上也在带来系统的功能的一种变革;最后是硬件平台。因此,我们觉得未来数据库发展的趋势:

    • 第一个是“One size fits a bunch”,为不同应用构建不同系统,为不同系统配置不同硬件。就像Michael Stonebraker说的那样,数据库不是一种系统就能应对所有的应用了。我觉得Stenberg当时是针对的是应用负载的增加带来的问题而提出的观点,但是硬件的发展瓶颈到来的时候,同样会引领我们认同这个观点,“One size does not fit all”,不可能为所有应用产生一个系统,应该是一类应用对应一套系统的,这个是我们看到的一个很明显的发展的趋势。

    • 第二个发展的趋势是现在的系统变多了之后,它需要协同,会有各种中间件,还会有各种形态的数据库,我们需要把它协同起来,这些数据库形态太多,对程序开发人员,维护人员都是一个Disaster,代价会变大,怎么更好地把它协同起来,这也是未来一个发展的方向,我们会看到这些系统相互之间会变得越来越配合,越来越融合。

    • 第三个就是云平台成为一个主流的硬件平台之后,我们看到数据库会朝云这个方向有更深入这种发展,它会更适合云这种形态,它的弹性,自我维护、自我修复的能力是会进一步提升的。这个是我们对未来发展的展望。

    02 华师大的数据库系统研究

     

    2.1 研究团队

                 

    然后介绍一下我们现在这个团队,华东师范大学数据科学工程学院大概有20多个老师,大概10个老师是从事数据库内核的研究的。整个团队的历史是超过20年的,我们近10年其实做了非常多的系统内核研发的工作,跟业界的很多的公司也有合作。我们的学生其实也做了很多工程性的工作。

    去年我们有拿到一个国家科技进步二等奖,这个是基于我们当时和某银行一起做的一款数据库产品,是我们基于OceanBase的一个早期开源的版本上实现的一个系统,具体的这种内容我就不做过多的介绍,这个系统实际上在某银行得到了比较深入的应用,是我们比较引以为豪的一个研究成果。

     

    2.2 研究成果

    我们团队的研究其实还是蛮广泛的,我们在事务型数据库和分析型数据库其实都有研究,但我们更多的精力还是集中在事务型数据库上面。然后接下来,我会介绍一些典型的研究成果,让大家了解一下我们的研究是在做一些什么事情,主要分三个部分,第一个是分布式事务,第二个是数据库系统解耦合,第三个是新硬件。

     

    2.2.1 分布式事务

    分布式事务是一个几十年来大家都在探讨的话题,实际上也是有一定的争论:分布式事务到底合不合用?我们在使用事务处理这种功能的时候,是不是应该去规避分布式事务?还是我们应该进一步去增强数据库支撑分布式事务的能力,让程序员不要刻意去规避分布式思维?这实际上是一个疑问,目前没有一个明确的答案。

    如果分布式事务确实是不行的,那我们就应该做一些其他方面的处理,来弥补分布式事务本身的缺陷,这样做有两种方式:

    • 第一种是干脆不要数据库提供分布式事务功能,将事务处理推给应用,根据应用的特点去规避这种分布式事务的一些缺陷。

    • 第二种是尽可能提升集中式事务处理的能力,集中式事务能够达到和分布式同样的效果,就不再需要分布式事务了。

    我们认为现在以NoSQL为代表的这些系统的推动者,实际上是持这样的观点的。比如典型的NoSQL客户系统MongoDB,它的一般的事务处理或者数据库的访问,都是Single Document一个文档一个文档去处理的。实际上,就是如果真要进行复杂的事务处理,那就到上层应用去处理,就用最定制化的方式去应对这种事务,它的效率可以比较高。

    另外一种观点认为分布式事务本身应该是可行的,我们应该提升数据库处理分布式事务的能力,解放开发者。

    这样的观点就是那些推动NewSQL这一类系统的人所持的观点,比如说谷歌的Spanner 、TiDB、OceanBase。那么想要把分布式事务做好,怎样去优化,提升分布式事务的能力?首先要处理异常,分布式事务最害怕的一个问题就是出现异常,出现异常之后,如果是一个分布式事务,一旦事务锁掉一个节点上的数据,另一个节点出现故障的话,就会很麻烦。那为了处理异常,然后以Spanner为代表,使用了很多高可用的系统架构,用Paxos/Raft创建这种在云平台,在这种廉价计算机上同样能够有高可用能力的基础设施,在这个上面我可以去规避分布式事务所遇到的这种异常的问题。

    但除了异常问题之外,实际上还有分布式事务的扩展性的问题。虽然分布式事务可以比较放心地应用于可靠的、高可用的系统上,但是它的性能会比较差。因此,我们必须要优化它的性能,为此学术界也做了很多尝试,对于团队来讲,最近几年,我们也做过一些研究和尝试。接下来我就大概讲一下我们的大概思路。

    首先,我们要了解到底是什么限制了分布式事务的扩展能力,大家是比较公认的一种观点是制约分布式事务扩展的主要是事物之间的这种阻塞Blocking。你可以想象一下,当一个事物它去访问一个数据,特别是修改一个数据之后,它会加锁,然后在加锁的过程中,又要去跟其他的节点进行各种通信。

    其实这种通信有时候是很耗时的,有时候甚至要跟异地的节点,比如说要做高可用,就需要跟异地的节点建立通信。在加锁的过程中去通信,由于通信的过程很长,然后就会把加锁的时长变得特别的长,阻塞就会变得很严重。一旦事务处理的阻塞时间增加,它的事物的吞吐有可能会受到很严重的影响,特别对于有一些热点的数据出现的话,不是时长增加一倍,性能就降低一倍的,有时候时长增加一倍,性能可能会降低若干倍,这是一个很麻烦的问题。

    所以说,真的想要解决分布式的扩展能力的话,在已经有高可用的前提下,我们最重要的目标就是要降低阻塞。怎样降低阻塞?其实可以用到很多的技术。比如说MVCC/OCC、 MVCC是多版本的数据管理,它可以降低阻塞,这个很直观,就是我一个数据有多个版本,当我的一个事务去改动数据的时候,我直接产生一个新的版本,这样就不用去阻止别人读你的旧版本。

    因为你有多个版本,新版本在产生的过程中,你没有办法去读,可以去读旧版本不用阻塞,这就是MVCC的使用。然后OCC也是一样的,就是OCC就是乐观并发控制,也就是说默认不需要加锁,到最后再来检测这个事务是不是执行正确,如果执行不正确推翻就行了。然后还有一些锁的优化,通过各种各样的技术,来把阻塞的现象把它尽量的减少,从而来提升分布式事务的扩展能力。

    MVCC时间戳分配去中心化

                 

    在MVCC上我们做过一些工作。当然MVCC有一个时间戳分配的问题,就是说它来判断一个事务或者一个数据或者一个数据的版本,它是不是应该由某一个事务去读取的话,它要通过一些时间戳的判断来做。时间戳的分配很麻烦,按道理来说,它是应该有一个中心的时钟,大家都去中心的时钟去拿时间戳,这样就可以保证事务处理正确无误。但通常如果有一个中心的时钟的话,那扩展性就受限了,比如谷歌的Spanner用一些原子钟去规避这个问题。然后我们做的一个研究就是去中心化,去优化了SI的隔离级别。

    SI是一种典型的MVCC的隔离算法或者并发控制的算法,它是需要时间戳的。我们做了一个去中心化。想法是我在给事务分配时间戳的时候,不是在事务开始的时候分配,而是在事务要结束的时候,根据它跟其他事务的关系、冲突情况,来给它指定一个合适的时间戳,所以叫后验时间戳,Posterior SI。这种方式使得我们可以不需要用一个中心的时间戳去做这个事情,但这个东西做起来其实蛮复杂的,我们大概5年前做了这件事情,最后有一些实验没有实现在现实的系统里面去,因为实现相对来说比较复杂,而实际应用中使用一个统一的中心的时间戳,基本的应用还是可以满足的。

                 

    我们做了很多的实验,实验结果可以表明我们的方法,当扩展到一定程度的时候,这种时间戳的分配是不会成为一个扩展性的瓶颈的。

    降低OCC的阻塞时间

    我们也做了一些OCC的工作。OCC在事务访问数据的时候,就放开让事务去访问,访问完了事务要结束的时候会做一个验证叫Validation,做完验证,再决定这个事务是提交还是回滚。这种方式也是降低事务之间阻塞的一种方法。其实这种事务的最后的正确性验证,有时候会挺耗时间的,所以在这个上面做了一个优化。

                 

                 

    我们认为做正确性验证的方式有两种,一种主要的方式叫Local Readset Validation,每个事务把它读过的数据记录下来,最后再去查读过的数据有没有被改动过。这种方式的缺点是当读取的东西特别多的时候,它的代价就会相当的大。

    然后,还有一种方式叫Global Writeset Validation,这种方式就是我不去记录每个事务读过的数据,只记录现在有多少正在运行的事务改动了那些数据,也就是说记录的是那些被改动的数据。然后读的时候,观察它的范围有没有包括改的数据,如果包括了验证就失败。这种方式对读取数据内容比较多的事务是友好的,但对那种小的、短的事务并没有那么友好。

                 

    所以我们就做了一个叫AOCC,Adaptive OCC,就是把这两种方式给结合起来,我们会判断一个事务的运行情况,如果读取的数据很多,就用Writeset Validation;如果读取得很少,就用Local Readset Validation,这样的话就把两种方式的优点结合起来。

                 

    我们做了一些实验,实际上结果确实证明这种方式没有极端的情况的缺陷。因为以前的那种就是读集Receipt Validation和Receipt,德行在在各自的极端情况下都会呈现出特别差的一个性能。但是我们这种方法实际上它是比较均衡的。

    跨区域高可用系统的锁时长

    然后第三个工作也是关于分布式事务的,就是我们做了类似于Spanner这样的系统,跨区域的高可用的系统。

                 

    就像我刚才提到的,一旦加锁,加锁的过程中,出现了跨区域数据的通信,这个持锁的时间就会特别的长。这里是一个例子,在跨区域高可用的系统上做的一个两阶段提交。可以看到红色的线是一个加锁的过程,这个过程已经是在一个正常的事务里面最短的加锁过程了,它是在事务提交开始之前加锁,一直到事务提交完成之后释放锁。

    对一个普通的事务来说,它本身就是要加锁的,但这个加锁的时间可以看到,在加锁过程中,Prepare阶段会有大量的本地节点跟异地节点之间的同步,然后在Commit阶段,同样的也有大量的本地节点跟异地节点之间的同步,这样的一个同步是很耗时间的,如果在这个时间上去做加锁的话,一旦遇到热点的数据访问,这个事务处理的性能就会极度的下降。所以在这样的条件下,我们就想可不可以用提前释放锁的方式去规避加锁,缩短加锁的长度,直接降低阻塞概率。

                 

    然后我们就设计了叫DLV,LV的意思是Lock Violation,实际上就是提前释放锁。DLV的话我们叫Distributed Lock Violation,同样是一个两阶段提交的一个协议。我们就看在什么地方释放所,它的效率是好的。我们选择了四个时间点:

    • 第一个是在 prepare阶段之前访问数据的时候,访问一个数据就放一个数据锁,相当于就不加锁,这是一种最极端的方式。但这种方式到后面的回滚率会非常的高,只能通过验证的方式来判断事务是否正确的执行,因此遇到死锁的情况也会很多,然后事务不正确的情况也很多。

    • 第二个时间点就是我们叫DLV1,就是在事务基本上数据访问的差不多了,但是协调节点还不太清楚,就是说所有的事务节点是不是已经完全做完了不太清楚,但是所有的事务节点各自都认为它自己做完的时候,这个时候释放锁。

    • 第三个时间点就是多加了一个协调的过程,协调的节点会跟所有的事务处理的节点做一个通信,通信完了之后,它认为这个时候所有节点都做完了,这个时候释放锁。

    • 第四个时间点就是两阶段提交的第一个阶段结束之后,再释放锁,这个是最安全的。

                 

    然后我们就实验了这些不同的加锁和释放锁的方式,得到的一个结论,左边这两张图(横轴是远程通信的时长)说明两个计算机中心离得越远,它通信时间越长,然后用这种传统的方式,会看到时长越长,它的性能就会越差。在高冲突的情况下,分布式事务处理性能就会比较差。但是如果使用提前释放锁的方式,性能就是绿色蓝色的线,表示着它的性能会有一个比较大的提升,这个就说明提前释放锁是有用的。

    但什么时候提前释放锁最合适呢?右边这个图我们做的一个实验最后的结论是第三个时间点就是DLV1x这种方式,协调节点跟事务处理阶段有一个短通信,这个是本地通信,不是异地通信,通信之后确认所有节点都做完了,这个时候释放锁,这样的负面作用是最少的,而且它的加锁时间也会很短,这种方式它的效率是最高的。

     

    2.2.2 数据库系统解耦合

                 

    我刚才介绍了三项研究,都是关于分布式事务处理的,然后我接下来再讲一讲我们在数据库系统解耦上面的一些研究,这也是非常有趣的一个问题。什么叫数据库系统的解耦?实际上教科书会把数据库系统拆成一个一个的模块,比如说这个是collector就是跟应用对接的连接器,还有Query Optimize、Query Evaluator或者叫Query Processor,就是查询处理查询优化的模块,New Storage Manager、New Transaction Manager,还有各种日志、Lock、Manager等等,这个是我们教科书上面对数据库一个模块的切分。

    但实际上当我们去真正的看一个数据库系统的实现,就会发现这些模块之间实际上没有切分的那么干净的,而且有时候是实际上模块之间很高耦合的,很紧的耦合在一起。对于一个刚开始做数据库的人会觉得跟我们学的东西会不完全一样。然后很少的人真的去探究为什么会是这样。我们在实现数据库系统的时候,实际上这种高耦合的系统架构给我们带来了很大的困扰。

    我们当时在某银行改那个OceanBase的系统时,改动一个数据类型,我记得好像花了好几个月的时间,很多人去做这个事情。这实际上一听上去会让人比较诧异,但实际上你去看系统的实现,它就是这么回事。一个数据类型好多地方都会用到,必须把每一个地方都清除掉,这个时候就必须花很多时间去读代码去理解去测试的。其实我们觉得如果一个系统的耦合度能够变低,模块之间能够分得很清楚,实际上对系统工程来讲是有很大收益的。

    我们回顾刚才讲的一个数据库的发展趋势,叫“One size fits a bunch”,也就是说我们认为以后系统会变得很定制化。如果一个系统的模块化做得很好的话,去定制去改动这个系统也会变得很简单。一旦一个新的硬件出现的时候,我们要去使用新的硬件去对这个系统进行优化,会变得更简单。

    其实一个数据库系统的实现,是有需要去做进一步的解耦合,这里面其实有很多问题。我们去做了一些探索,但其实是非常有限的探索,我觉得这个工作其实可以有更多的人去做。我们做的探索,就是说想把并发控制直接从数据库的存储层抽离出来,然后让存储的代码跟并发控制的代码尽量的互不相关。

                 

    这是一个B-Tree的Search Function的例子,在教科书里面,关于B-Tree的Search,你可能会看到这样一个代码,非常简单。

                 

    但实际上一个B-Tree的Search没有那么简单,可以看到这里面有好多的东西,这还只是一个例子。如果对开源系统比较熟悉的话,一般的一个开源系统的B-Tree,差不多要将近十万行代码,非常复杂。

    这个代码为什么这么复杂?可以看到B-Tree里面有很多的锁,有比如Latch、Lock之类的很多东西,它实际上是在做并发控制。当然并发控制只是导致代码复杂的原因之一,但还有其他的原因,并发控制把这个代码变得远远的复杂于B-tree本身功能的程度。其实这就是数据库解耦合的一个动机,如果可以把耦合度解开,并发控制可以交给一个单独的模块去做,B-Tree的代码就可以像第一个例子那样写,事情就变得很简单。

                 

    于是,我们就想如果把CC就是并发控制从数据库这种体系里面解耦出来应该怎么做?有很多种方式,最左边的这种其实是比较传统的方式,这种方式实际上并没有让数据库存储层变得更简单,只是在存储地上面做了一个事务处理层,这是一个比较浅的做法。中间的这种就是一个很暴力的做法,它是在物理的存储上面加一个Transaction Tier,然后在上面做存储做运算。

    大家应该听说过Transactional Memory,就是事务内存,这种就是直接用事务内存做事务处理,是一种很暴力的方式。最右边是我们提出来的方式,把并发控制的层次分成了两层,一种是我们叫操作层的并发控制,一种是事务层的并发控制,把它们合在一起变成一个新的模块。实践下来肯定是我们这种方式效果明显地更好,这种很暴力的事务内存的方式,实际上性能是不可以接受的。

    我们其实看到现在有一些做存储的同学,他有一些比较天真的想法,他认为把事务做到存储的最底层,然后上面就不需要关心事务了,实际上那是不行的。事务是跟系统的功能是有很多耦合的因子在里面的,不能完全把它抛弃掉。然后最左边这种方式的结果是不彻底的,实现B-tree的时候还是会挺复杂的。然后我们提出的这种方式,可以清楚的把CC给抽离出来。

                 

    这个事情其实并不是那么的简单,上面是一个很简单的例子,A和B是两个物理数据,然后在数据库的数据结构里面,定义两个引用(Reference),A1和A2,B1和B2,A1和A2都是指向A的,B1和B2都是指向B的。上面的事务层实际上是对A1、A2、B1、B2进行访问的。这个时候如果只是通过逻辑层去决定事物跟事物是否冲突的话,是会出错的。因为这里的逻辑层跟物理层,有一个重复引用的关系,可以看到下面这个事务处理的Schedule,从A1、A2、B1、B2这种方式去看,好像这两个事务这样处理是没问题的,它是有这种可串行化的能力的,但实际上并没有,因为A1和A2指向的是同样一个数据。

                 

    这种实际上就是说如果真的要去把这个事务抽离出来的时候,会有很多的问题需要去解决,我这里没有办法深入地探讨,总之我们做了这样一个尝试,我们叫Transparent Concurrency Control(TCC),就是透明的并发控制的一种模式。

    我们把这个事务层抽成两层,一个是事务层次的并发控制,一个是操作层次的并发控制,让这两种东西能够配合起来使用。然后用户去编写程序的时候,他可以不要去关心操作层面的并发控制,他直接去写他的B-Tree就行了。但是写好B-Tree之后,在事务层次上的这种并发控制,需要提供一些语义的信息说明哪种操作跟哪种操作之间实际上是不会冲突的,这样整个事务处理过程就可以保证正确性和高效性。

                 

    我们做了一些实验,去验证这样的一个解耦。右边的这些图,这种圆圈的线代表原始数据库实现的性能,可以看到我们的方式(TCC)的性能在很多情况下可以接近原始数据库的性能,这是解耦之后数据库的表现。很多时候解耦之后的表现可以接近原始数据库的性能,所以我们觉得这种解耦实际上还是可行的。但如果真的要把它用到一个现实的系统当中,其实并没有那么简单。这是我介绍的第二个研究工作,就是我们在数据库解耦上面的一些有趣的发现。

     

    2.2.3 新硬件

                 

    最后我再谈一谈新硬件,就是这种非易失内存。英特尔的傲腾是现在市面上唯一的一个真正的非易失内存产品,图中是产品的相关指标。对于存储器件的话,我们一般看两个指标,一个是带宽,一个是延迟。

    可以看到它的带宽和延迟都是远远超过SSD,当然更加超过这种硬盘。它的价格会比SSD和硬盘要昂贵不少,但相对于内存而言,它还是便宜的,我们可以预测它后面会越来越便宜,它跟SSD之间的一个价格的差异会变得越来越小,所以以后它有可能会取代SSD这种固态硬盘,但是不会太早。这种新的存储,它的性能更好,又比内存的造价低,所以它以后在系统当中肯定是有很重要的一个位置的。现在有了这种硬件之后,我们需要讨论在数据库系统里面,这个硬件到底起什么作用,一个新的数据库的架构应该怎么去使用它?怎么定位它的价值和位置?

                 

    我们团队对这个东西讨论了很长的时间,最后有一个这样的设计,首先非易失内存这个东西,当然要用到数据库里面,数据库有各种形态的数据库,不同的形态的数据库使用方式是不一样的,但我们最后把它定位在云的数据库上面,因为我们知道云是未来的最主要的架构。在云的数据库上面怎么去用这个东西,我们觉得它跟RDMA的使用应该结合在一起。

                 

    现在的云数据库变成一种计算节点跟存储节点是相对分开的架构方式。然后一旦NVM加进来之后,我们希望它成为计算节点跟存储节点之间的一个缓存。我们觉得现在暂时不能用它来做全量数据的存储,因为它的价格实在是比较昂贵,很多冷的数据,完全没有必要存在这样昂贵的存储里面,所以它作为一种缓存,比较合适的。

    另外一方面,它作为一个缓存,不应该是一个割裂的节点,因为我们去看它的性能指标,可以看到实际上这种非易失内存的吞吐、延迟,和在高速网络上的RDMA的吞吐和延迟是比较接近的。如果比较接近的话,这个器件是通过RDMA的远程去访问,还是通过本地访问的速度差异有可能并不会很大。如果这个速度的差异并不会很大的话,我们实际上是可以把多个节点的NVM联合在一起,作为共享的缓存,缓存共享有非常多的优势,省去了很多缓存数据同步的代价,然后还可以让系统的负载均衡变得更好。

    我们决定去设计这样一个系统架构。这个是NVM,我们叫存储节点和计算节点之间的一个缓存。

                         

    我们这个事情正在做的过程中,所以目前为止我们是实现了一个分布式的缓存,可以作为共享缓存来用。我们开始讨论它应该是作为数据库而言,是行级别的缓存还是块级别的缓存,最后我们的选择是块级别的缓存,主要的原因还是因为实现起来更简单。我们先试一试,如果做到行级别的缓存的话,是有很多的工作量的,我们后期可能还会去尝试。

                 

    然后缓存的基本的测试,我们觉得我们的实现基本已经到位了,就是它的带宽的瓶颈基本上压到了RDMA访问带宽的瓶颈,如果要对它进行读写的话,它的瓶颈基本上就是RDMA远程访问的瓶颈,然后它的性能是远远高于像Redis这样的一个系统的,我们希望用这个缓存把它放在数据库里面,去提升这种云数据库的一个性能,但这个过程我们还在实现当中,我们有一些初步的结果,它是有一些效果的,特别是面对底层是SSD或者磁盘这样的系统的时候。我们希望后面有更明确结果的时候,再给大家介绍。

    03 相关论文列表

           这是我们实验室的一些代表性论文,不是很全,我刚才讲的部分技术并不在列,因为还没有公开发表。如果感兴趣的话,大家可以阅读一下。

    写在后面

    华东师范大学周烜教授也是2020-2021年度美团科研课题合作学者。当前美团技术团队与超过30位来自国内外高校和科研院所的学者建立了科研课题合作。美团科研合作计划,基于美团在生活服务领域全场景里提炼出的科研命题,面向学术界征集前沿解决方案。

    我们致力于与学术界“一起解决真实世界的问题”,愿与学术界共同推动产学研成果落地。2021年将更加精彩纷呈,敬请期待。

    ----------  END  ----------

    也许你还想看

    美团内部讲座|清华大学莫一林:信息物理系统中的安全控制算法

    | 美团内部讲座|北航全权:一种城市空中移动性管理分布式控制框架

    喜讯!美团-清华大数据课程对外开放啦!

    展开全文
  • 假设数据库有一张表t_mail (id, from, to, subject, content), 里面存储着具体的邮件发件人、收件人、标题和内容。采用Druid连接池,读取id为1的记录,并基于Java Mail将该邮件发送出来。 import java.sql....

    假设数据库有一张表t_mail (id, from, to, subject, content), 里面存储着具体的邮件发件人、收件人、标题和内容。采用Druid连接池,读取id为1的记录,并基于Java Mail将该邮件发送出来。

    import java.sql.Connection;
    import java.sql.ResultSet;
    import java.sql.SQLException;
    import java.sql.Statement;
    
    /*
     * 假设数据库有一张表t_mail (id, from, to, subject, content), 
     * 里面存储着具体的邮件发件人、收件人、标题和内容。
     * 采用Druid连接池,读取id为1的记录,并基于Java Mail将该邮件发送出来。
     */
    public class DBMailSend {
    
    	public static void main(String[] args) {
    		Connection conn=null;
    		String from;
    		String to;
    		String subject;
    		String content;
    		String password;
    		String smtpServer;
    		try {
    			//从Druid获取
    			conn=DruidFactory.getConnection();
    			System.out.println("连接池构建成功");
    			
    			//构造数据库执行者
    			Statement stmt=conn.createStatement();
    			System.out.println("获取连接成功");
    			
    			//执行SQL语句并返回结果到ResultSet
    			ResultSet rs=stmt.executeQuery("select id,mfrom,mto,msubject,content,password,smtpServer from t_mail order by id");
    		    System.out.println("获取数据成功");
    		    
    		    //开始遍历ResultSet数据
    		    while(rs.next()) {
    		    	System.out.println(rs.getInt(1)+","+rs.getString(2)+","+rs.getString(3)+","+rs.getString(4)+","+rs.getString(5)+","+rs.getString(6)+","+rs.getString(7));
    		    	
    		    	if(rs.getInt(1)==1) {
    		    		from=rs.getString(2);
    		    		to=rs.getString(3);
    		    		subject=rs.getString(4);
    		    		content=rs.getString(5);
    		    		password=rs.getString(6);
    		    		smtpServer=rs.getString(7);
    		    		MailClientSend client=new MailClientSend(from,password,smtpServer);
    		    		client.init();
    		    		client.sendMessage(from, to, subject, content);
    		    		System.out.println("发送邮件成功");
    		    	}
    		    	
    		    }
    		}catch(Exception e) {
    			e.printStackTrace();
    		}finally {
    			try {
    				if(null!=null) {
    					conn.close();
    				}
    			}catch(SQLException e) {
    				e.printStackTrace();
    			}
    		}
    
    	}
    
    }
    import java.sql.Connection;
    
    import com.alibaba.druid.pool.DruidDataSource;
    
    public class DruidFactory {
       private static DruidDataSource dataSource=null;
       
       public static void init()throws Exception{
    	   dataSource=new DruidDataSource();
    	   dataSource.setDriverClassName("com.mysql.cj.jdbc.Driver");
    	   dataSource.setUsername("root");
    	   dataSource.setPassword("123456");
    	   dataSource.setUrl("jdbc:mysql://localhost:3306/test?serverTimezone=UTC");
    	   dataSource.setMinIdle(1);
    	   dataSource.setMaxActive(10);
    	   
    	   //启动监控统计功能 dataSource.setFilters("stat");
       }
       public static Connection getConnection()throws Exception{
    	   if(null==dataSource) {
    		   init();
    	   }
    	   return dataSource.getConnection();
       }
    }
    
    import java.util.Properties;
    
    import javax.mail.Authenticator;
    import javax.mail.Message;
    import javax.mail.PasswordAuthentication;
    import javax.mail.Session;
    import javax.mail.Transport;
    
    public class MailClientSend {
        private Session session;
        private Transport transport;
        private String username;
        private String password;
        //private String smtpServer="smtp.qq.com";
        private String smtpServer;
    	
        public MailClientSend(String username, String password, String smtpServer) {
    		super();
    		this.username = username;
    		this.password = password;
    		this.smtpServer = smtpServer;
    	}
        
        public void init()throws Exception{
        	//设置属性
        	Properties props=new Properties();
        	props.put("mail.transport.protocol", "smtp");
        	props.put("mail.smtp.class", "com.sun.mail.smtp.SMTPTransport");
        	props.put("mail.smtp.host", smtpServer);//设置发送邮件服务器
        	props.put("mail.smtp,port","25");
        	props.put("mail.smtp.auth", "true");//SMTP服务器需要身份验证
        	
        	//创建Session对象
        	session=Session.getInstance(props,new Authenticator() {//验证账户
        		public PasswordAuthentication getPasswordAuthentication() {
        			return new PasswordAuthentication(username,password);
        		}
        	});
        	//session.setDebug(true);//输出跟踪日志
        	
        	//创建Transport对象
        	transport=session.getTransport();
        	
        }
        public void sendMessage(String from, String to, String subject, String body)throws Exception{
        	//创建一个邮件
        	TextMessage tmsg=new TextMessage(from,to,subject,body);
        	
        	Message msg=tmsg.generate();
        	
        	transport.connect();
        	transport.sendMessage(msg, msg.getAllRecipients());
        	//打印结果
        	System.out.println("邮件已经发送成功");
        }
        public void close()throws Exception{
        	transport.close();
        }
        
    }
    
    import java.util.Date;
    import java.util.Properties;
    
    import javax.mail.Message;
    import javax.mail.Session;
    import javax.mail.internet.InternetAddress;
    import javax.mail.internet.MimeMessage;
    
    public class TextMessage {
        private String from;//发件人地址
        private String to;//收件人地址
        private String subject;//标题
        private String body;//正文
    	
        public TextMessage(String from, String to, String subject, String body) {
    		super();
    		this.from = from;
    		this.to = to;
    		this.subject = subject;
    		this.body = body;
    	}
        
        public MimeMessage generate()throws Exception{
            //创建Session实例对象
            Session session=Session.getDefaultInstance(new Properties());
            //创建MimeMessage实例对象
            MimeMessage message=new MimeMessage(session);
            //设置发件人
            message.setFrom(new InternetAddress(from));
            //设置收件人
            message.setRecipients(Message.RecipientType.TO, InternetAddress.parse(to));
            //设置发送日期
            message.setSentDate(new Date());
            //设置邮件主题
            message.setSubject(subject);
            //设置纯文本文件内容的邮件正文
            message.setText(body);
            //保存并生成最终的邮件内容
            message.saveChanges();
            
            //把MimeMessage对象中的内容写入到文件中
            //msg.writeTo(new FileOutputStream("e:/test.eml));
            return message;
        }
        
        
    }
    

    数据库表格如下:

    注意:from 为SQL关键字,故不能作为表格字段,因此用mfrom替换

    展开全文
  • SCIE(科学引文索引)收录华东师范大学论文统计与分析,郑伟,,以美国公司的网络数据库为依据,对华东师范大学1981年-2004年间被收录的论文从收录量、著者单位、引用次数、发表期刊等几方面进行了
  • 在上海鲲鹏计算产业峰会上,华东师范大学与华为正式启动了GaussDB数据库创新合作。双方将深入进行数据库领域的联合创新,同时启动产业人才培养合作计划。 ▲ 华东师大和华为GaussDB...

    在上海鲲鹏计算产业峰会上,华东师范大学与华为正式启动了GaussDB数据库创新合作。双方将深入进行数据库领域的联合创新,同时启动产业人才培养合作计划。

      ▲ 华东师大和华为GaussDB数据库创新实验室启动仪式

    根据本次达成的共识,基于当前数据多样化和硬件革新的新趋势,华为将协助华东师大开设GaussDB数据库实践、实训课程与数据库课程实验室, 并提供专项的人才实习岗位。借助此合作平台, 双方将共同培养合格的数据库从业人员和核心开发者群体,为中国数据库人才生态做出贡献。

    华东师大副校长周傲英教授在大会演讲中指出:“数据是人类文明史上继蒸汽能和电能之后的第三个能源,是催生数字经济的新动能。大数据凸显了数据的人本特性,新时代的信息化就是充分发挥数据的威力,用技术助力实现为人民服务的根本宗旨,促进政府治理现代化和人的现代化,建设数字中国,并在此过程中实现技术和科学的创新。”

    周傲英认为,“华为与华东师大的合作是强强联手,双方紧密合作将共同为中国智能数据产业升级做出新贡献”。

    华为高级副总裁 、Cloud &;AI产品与服务CTO张顺茂表示:“华为非常重视生态的力量, GaussDB可以利用鲲鹏多核以及超并行计算技术,构筑了软硬件全栈的数据库能力, 是产业生态中重要的一环。华为秉承‘硬件开放、软件开源、 平台+生态’的理念,持续积极地与包括高校在内的开发者进行互动。华为与华东师大在数据库方向的创新合作,以及全国高校金种子发展计划, 一定可以让华为能够为下一代的数据库核心开发人群培养做出一些应有的贡献。”

    华东师大数据科学与工程学院院长钱卫宁教授表示:“华东师大数据科学与工程学院是最早的数据学院,承载着高校在数据科研领域进行前沿探索的使命。华为是ICT领域的龙头企业,我们双方在交流中,无论在科技前沿还是人才培养都有着高度的共识。华东师大数据科学与工程学院, 希望能够在国产数据库产品的技术和应用创新,技术落地和产业化,在中国数据库核心人才培养方面, 做出积极贡献。”

    华为IT产品线副总裁、智能数据与存储产品线总裁周跃峰认为,数据基础设施是数字经济的基石底座,也是华为公司的重要战略方向。产业的繁荣需要产学研的共同紧密合作,并构建一个良好的用户生态。华东师大不仅有领先的科研团队,作为师范院校更是在数据科学教育方面具备领先的教育理念。周跃峰表示,我们真诚希望和华东师大在数据库的科研与人才培养方面进行长期深入的战略合作。突破更多的技术课题, 培养出大量的数据库核心人才,并且为中国基础数据科学教育做出积极贡献。

    华东师大周烜教授围绕数据库技术趋势,与华为数据库课题合作的理念,包括区块链数据库、场景驱动的数据库系统测试方面, 以及华东师大在数据科学与工程领域人才培养的优秀实践方面做了深入解析和现场交流。

    合作数据库简介

    区块链数据库

    随着以支持智能合约为代表的区块链2.0平台的推出,区块链技术的应用已经从单纯的数字货币,延伸到包括数字资产交易、物联网、 智能制造和供应链管理等很多传统领域。

      区块链数据库合作包括:

      ► 增加密码学安全基础设施,为防篡改提供密码学安全支持;

      ► 增加多方共识机制,在多个参与方之间保证数据一致;

      ► 高吞吐、高存储效率,适应企业级的数据管理需求。

    合作成果将适用于包括电子商务交易系统等场景,主要应用于多方参与、而又互不信任下开展的分布式商业活动下的数据管理。

    场景驱动的数据库系统测试

    数据库系统测试是保障系统稳定性、可用性,提升系统性能的基础。传统的测试数据和测试负载生成技术,由于生成数据和生成负载与应用的弱相关性,基于其得到的评测结果对于特定应用来说很可能不具有参考价值。同时,对于数据库系统的质量管理来说,评测基准的负载相对有限,无法保证测试的全面性。

    另一方面,当前测试数据和测试负载的生成技术也无法实现大规模事务负载的自动化生成,因此数据库系统对于事务型负载,尤其是高压、高冲突的事务型负载,难以得到充分评测。

    课题合作包括测评系统与应用强关联,和实现大规模事务负载的自动化生成。合作成果将适用于包括面向分析和事务型应用的负载生成,和大规模TP测试负载生成与正确性自验证场景。

    新闻来源:华东师范大学

    21考研的QQ群,有各个学校的考研资料,欢迎加入

    群号是 954288959


    您还可以在以下平台找到我们

    你点的每个在看,我都认真当成了喜欢

    展开全文
  • 区块链与分享型数据库钱卫宁,金澈清,邵奇峰,周傲英华东师范大学数据科学与工程学院,上海 200062摘要:区块链可以实现无中心、高可信的账本管理,成功支撑了比特币等金融领...
        

    区块链与分享型数据库

    钱卫宁,金澈清,邵奇峰,周傲英

    华东师范大学数据科学与工程学院,上海 200062

    摘要:区块链可以实现无中心、高可信的账本管理,成功支撑了比特币等金融领域应用发展。区块链的本质是在不完全可信环境中的可信数据管理,它具有去中心化、防篡改、强一致和完整性等特性。同时,区块链也存在着数据管理功能弱、性能低等问题。通过对比区块链和传统数据管理技术,分析3个典型的金融领域以外的区块链应用,探讨区块链上新的研究问题,并讨论面向特定领域应用,研发分享型数据库系统(即支持核心业务,支撑分享经济业务模式,甚至本身也是以分享经济的方式实现的数据库)的必要性。

    关键词:区块链;分享型数据库;数据管理

    doi:10.11959/j.issn.2096-0271.2018004

    640?wx_fmt=jpeg

    论文引用格式:钱卫宁, 金澈清, 邵奇峰, 等. 区块链与分享型数据库[J]. 大数据, 2018, 4(1): 36-45.

    QIAN W N, JIN C Q, SHAO Q F, et al. Blockchain and sharing database[J]. Big Data Research, 2018, 4(1): 36-45.

    640?wx_fmt=jpeg

    1  区块链

    自2008年10月31日署名为“中本聪”的比特币(Bitcoin)文章发布以来,加密数字货币已经展示了构建一个大型、去中心的分布式账本的可能性。2014年10月22日, 在大英图书馆举办的盛宝银行研讨会中,多位发言人都认为在比特币风潮的背后,区块链(blockchain)是真正有趣的技术。几乎同时,相对于比特币的“区块链1.0”技术,被认为是“区块链2.0”技术代表的以太坊[1]项目发布,而Hyperledger项目也随后在2015年发布。时至今日,区块链已成为一大批应用的支撑技术。

    虽然区块链技术发展迅速,区块链系统、平台、应用层出不穷,但是它们大都具备以下5个特点。

    首先,它们都具有链式结构,如图1所示。数据或交易信息被组织成区块;一系列区块构成链;通过对前趋区块进行数字签名,并将签名放入后继区块,构造、维护区块间的链接关系。区块内交易信息的顺序组织以及区块间的链式结构能够准确记录交易流水,实现账本的功能。

    640?wx_fmt=jpeg

    图1 区块链的链式结构

    其次,区块链是防篡改的。区块内常用Merkle-tree[2]或其变种生成区块的摘要信息,用于区块内容正确性校验,而因为前趋区块的签名是后继区块的一部分,所以一个区块其实包含了自链首开始的全部信息的摘要,可用于之前信息是否篡改的校验。换言之,要修改一个已记录在区块链中的交易,需要修改其所在区块后的所有区块内容,这往往需要极大的计算量或系统中大量节点的配合,因此通常难以实现,从而实现了防篡改。

    第三,区块链的存储是分布式、去中心的,不依赖于单一中心节点。区块链被多副本地存放在多个节点上。区块链的更新需保持副本的同步更新。根据需要,节点间的分布式共识协议可以采用工作量证明(proof of work,POW)、实用拜占庭容错(practical Byzantine fault tolerance, PBFT)[3]、拜占庭容错Paxos[4,5]或权益证明(proof of stake,POS)等。虽然去中心的架构摆脱了单点故障的问题,提升了系统的顽健性和防篡改的能力,但同时分布式共识协议也导致了较大的数据修改时延和很低的系统吞吐率。

    第四,虽然支撑比特币的区块链只能支持简单的交易记录和查询,但是新的区块链平台大都支持智能合约。智能合约指“以数字形式定义的承诺,包括合约参与方可以在上面执行这些承诺的协议”。它常用图灵完备的通用编程语言或专用语言实现,用以定义区块链平台中复杂的商业逻辑。错误的智能合约实现可能引发严重的系统安全问题[6]。

    第五,当前区块链技术和系统的另一个重要特点是它们常和金融应用(如加密货币、分布式账本[7]、单据管理、首次代币发售和众筹[8]、慈善等)紧密关联。区块链技术以分布式、点对点的方式,提供了可信的账本管理功能。

    目前已有大量工作探索区块链的基础理论、实现方法、应用模型。本文试图从数据管理的角度梳理区块链技术,并从3个区块链应用出发,讨论区块链技术研究的需求与挑战。

    2  数据管理的本质

    在讨论区块链的数据管理问题之前,首先简要介绍数据管理的核心问题。

    广义的数据管理包含数据的获取、存储、处理、利用等各个方面的问题。数据管理任务通常由数据库管理系统(database management system,DBMS)和相关工具承担。自20世纪70年代关系数据库理论诞生以来, 关系数据库管理系统(relational database management system,RDBMS)由于其在各类数据管理应用,特别是“关键任务(missioncritical)”应用中表现出的良好易用性、通用性和性能,成为大量数据管理任务的首要甚至是唯一选择。伴随着RDBMS产业的壮大,数据库理论以及存储、索引、查询执行、查询优化、事务处理、并发控制等一系列数据库技术发展迅速[9-11]。

    数据管理的核心问题包括数据及其处理方法的建模、数据管理任务实施和管理、系统性能优化及其实现、系统的运维等多个方面。

    2.1  数据模型抽象

    数据模型的管理是数据管理的重要任务。数据模型包括数据结构、数据操作以及数据的完整性约束。正是由于提供了数据模型的抽象,数据管理系统才能服务于不同应用,以统一的形式实现数据的增、删、改、查功能。

    应用最广的数据模型是关系模型(relational model)。它将集合论和数理逻辑作为理论基础,将被广泛接受和使用的SQL语言用于数据定义、数据操纵、数据控制和事务控制。SQL语言是声明型语言,与过程型的语言相比,简化了开发者编写数据库应用的过程。

    由于关系数据库管理系统的巨大成功,很多时候,谈论数据管理时就是指采用RDBMS进行数据管理。实际数据管理系统中采用的数据模型常是关系模型的扩展,如 对象—关系模型(object-relational model),它在关系模型的基础上添加了用户定义类型(UDT)、用户定义函数(UDF)、触发器(trigger)等功能[12]。

    2.2  数据处理抽象

    数据模型是对数据的抽象,而事务则是对数据处理流程的抽象。在RDBMS中,事务同样由SQL语言实现。事务需要满足事务语义,即“ACID”性质,指事务的原子性(atomicity)、一致性(consistency)、隔离性(isolation)和持久性(durability)。正是由于有了事务处理,数据管理系统才可以实现以记账和订票为代表的关键任务应用中的数据管理,在充分利用系统硬件资源的同时,实现正确且高效(低时延、高通量)的数据处理[11]。

    为了实现事务处理,DBMS提供了并发控制和恢复机制,前者主要用以保障事务的一致性和隔离性,而后者则主要保障原子性和持久性。DBMS中常需要维护数据在系统内多个副本之间的一致性,如多个存储节点之间或磁盘与缓存之间的一致性。这些副本存在于一个相对可信的系统环境内部,因此其一致性维护需求不同于区块链中分布式共识机制面对的需求。

    在恢复机制中,常采用数据库日志记录对数据进行的操作和事务的提交、终止操作。数据库日志从形式上与区块链中顺序记录的交易流水类似。它们的不同点在于, DBMS中的日志存储介质是可信的,一般并不采用签名对整个日志序列进行防篡改保护。另外,DBMS中的日志通常只在数据库恢复时使用,而在很多区块链平台中,交易流水记录是唯一的数据,因此也是数据查询的对象。

    DBMS提供多种形式的事务接口。存储过程是一种常用的事务形式,它是预先编写好的事务程序,存储于服务器,被客户端调用后执行,并在执行结束后将执行结果返回给客户端。

    为了解决客户端用过程型语言编写的程序和数据库服务器声明型语言的集合数据访问之间的“阻抗失配(impedance mismatch)”问题,DBMS通常提供游标(cursor)功能,供客户端程序以逐行记录为单位与数据库服务器进行交互。

    2.3  独立性与透明性

    DBMS提供的接口是声明型的,其由系统自身实现。在实现时,系统提供了三层视图和两层映射,即视图(外模式)—概念模式(模式)—物理模式(内模式)三者之间的映射,如图2所示[10]。这样,当数据的存储组织变化或应用需求变化时,只需要修改相应的模式映射关系,不用修改系统的其他部分,从而节约了系统和应用的开发和维护成本。

    640?wx_fmt=jpeg

    图2 数据管理的三层视图、两层映射

    2.4  性能

    提供数据管理独立性与透明性的同时, DBMS将应用开发者隔离在查询执行和事务执行的具体细节之外,承担了大部分的性能优化问题。而性能是DBMS数据管理的关键问题。最早的RDBMS——S ystem R的主要开发者之一Bruce Lindsay认为数据库世界最重要的事情就是系统性能[13]。现代DBMS通过缓存、索引、查询执行、查询优化、并发控制等技术,实现查询和事务的计划优化和执行优化,如图3所示。近年来,随着大容量内存、高速网络、多核/众核处理机技术的快速进步,现代DBMS也常通过内存数据库、分布式数据存储、查询和事务的并行执行等技术提升系统性能。

    640?wx_fmt=jpeg

    图3 数据管理系统功能体系结构概览

    2.5  工具与编程接口

    除数据模式管理、查询和事务处理以外,DBMS的管理、运维工具也是数据管理中的重要方面。1998年图灵奖获得者Jim Gray认为,易用、易管理是数据管理系统要实现的重要目标[14]。此外,随着近年来互联网技术的发展,应用的规模越来越大,涉及的子系统、数据源数目也逐步增加,因此数据集成也是数据管理的重要方面,需要专门的工具配合DBMS使用[15]。

    3  作为数据管理系统的区块链

    从数据管理角度看,区块链是一个构建在对等网络上、采用链式存储的可信数据管理系统。将区块链与传统的数据管理系统进行对比,有助于发现区块链数据管理系统的基础理论、实现方法的新研究问题,也有助于为这种新的数据管理系统寻找新应用,为改造现有的技术和系统、适配新型应用提供启发。

    3.1 技术对比

    表1列举了区块链与传统RDBMS的主要相似点和区别。首先,两者都有顺序组织的链式结构,区别只在于其作用不同,区块链的链式结构就是数据的存储组织形式,而RDBMS的日志则主要用于数据恢复。区块链中并不单独存储数据库的当前状态,而数据库的快照是RDBMS中支撑索引、查询等优化技术的基础。

    表 1 区块链与 DBMS 对比

    640?wx_fmt=png

    其次,RDBMS通常只提供一定程度的硬件容错,但并不支持防篡改。防篡改是区块链在对等网络中确保数据可信的最重要特性。

    第三,区块链,特别是公有链,是完全去中心化的,构建于对等网络。即使是联盟链,虽然有些系统采用主链—支链的形式组织节点,但是区块链的各项实现机制都假设无中心节点存在。与之相反,传统数据管理系统都是强中心的,且认为中心节点是可信的。这直接导致了在确保数据一致性时,区块链系统采用的分布式共识算法通常只在分布式数据库管理系统中用以维护元数据。这是两者性能差异巨大的最主要原因。

    第四,当前的主要区块链平台并不提供所管理数据的模式管理。因此数据访问方式也相应地只提供过程型的应用程序编程接口(application programming interface,API)。缺乏声明型的接口为复杂数据管理任务应用的开发制造了困难,也成了区块链系统与现有数据管理系统交互和衔接的屏障。

    此外,智能合约与RDBMS中的触发器和存储过程具有相似性。值得注意的是,在很多大型的关键任务应用中,为了保持高性能以及遗留代码的可维护性,常避免采用触发器和存储过程。

    最后,区块链和传统RDBMS面向的应用不同,区块链正在承担越来越多的金融领域跨部门、跨机构、跨组织甚至跨行业的可信数据管理任务。

    区块链和RDBMS的区别不仅体现在架构、功能和实现技术上,还体现在性能上。当前性能较好的区块链平台的数据访问吞吐率见表2[16]。而根据 事务处理性能委员会(TPC)的数据,在TPC-C基准评测下,吞吐率能达到近5万 TPS(transaction per second)。需要注意的是,TPC-C的负载复杂度远远超出当前区块链平台能支持的查询和事务处理复杂度。和RDBMS相比,区块链的性能劣势限制了它在很多需要承受高负载压力的关键任务应用中的推广和使用。

    表 2 部分区块链系统性能640?wx_fmt=png

    3.2 面向领域的数据管理系统

    传统数据管理系统的设计、实施、应用开发逻辑是“一体适用(one-size-fitsall)”的,即DBMS是通用的,适用于任何领域的任何(结构化)数据管理任务。关系数据库管理系统产业的兴起和发展也依赖于这一指导思想。2005年,Stonebraker M[17]对这一指导思想提出了疑问。10年以后,获得2014年度图灵奖的Stonebraker M则很明确地宣告传统DBMS不再适用于任何应用场合[18]。这既是由于新硬件的快速发展颠覆了传统DBMS研发时基于的假设,也是因为应用的多样性导致一个系统优化、平衡所有功能和性能指标是不可能的。

    随后,另一位重要的数据库学者Carey M[19]提出了更具建设性的指导思想,即“分类适用(one size fits a bunch)”,针对一个特定领域的特定需求,设计专用的数据管理系统,例如高通量事务处理需要NewSQL系统、联机分析处理(online analytical processing,OLAP)需要列存储的数据库、文本搜索需要检索系统、海量和流数据处理需要流数据处理系统、信息网络的数据管理和处理需要图数据库,不一而足[20]。

    区块链正是满足加密货币应用的可信记账需求而生的专用数据管理系统。于是,有两个问题:区块链是否也适用于其他可信数据管理任务?如何借鉴区块链技术解决更广泛或其他领域的可信数据管理问题?

    4  应用与讨论

    4.1  应用1:基于区块链的智能仓单管理系统

    2016年,针对钢铁商品仓单抵押常见的虚假仓单、重复抵押等问题,研发了基于区块链的智能仓单管理系统,提供仓单生成、流通、交易等各环节的可信管理,其应用架构如图4所示[21]。这是一个典型的联盟链应用,相互协作的多个节点(机构)通过区块链共同管理仓单数据和仓单的交易、流通信息。与比特币不同,链上的节点对信息的操作和使用方式不同。链上有仓单的拥有者(货主)、管理者(仓库)、监管者(监管公司)、查询者(金融机构)以及仓单抵押、流通、交易过程中涉及的扮演各种角色的节点。

    640?wx_fmt=jpeg

    图4  区块链的智能仓单管理系统应用架构

    针对仓单数据的结构化特点,系统实现了数据模式管理。参与单位常需要同时对链上的仓单信息和本地数据库信息进行关联,进而进行分析处理。系统在区块链的基础上,实现了链上、链下数据的一体化查询处理。

    4.2  应用2:数据流通

    安全屋是上海优刻得信息科技有限公司的数据流通云服务平台。数据在安全屋内共享,进行分析处理。在安全屋内,一切数据访问、数据处理行为都被监管与审计,只有数据处理结果可被“带出”安全屋。系统中进出的数据与处理过程都使用区块链进行记录,供后续审计和分析使用。

    当前的区块链技术不足以支撑安全屋的所有记录和监管需求。一方面,数据分析包含大量机器学习和人工智能算法处理,比单纯的交易记录和事务处理要复杂很多,数据处理的记录方式以及后续的审计方法都需要进一步探索。另一方面,安全屋内数据处理流程审计的本质是对数据项处理过程的回溯查询[22],当前的区块链平台对于回溯查询支持仍较弱。

    4.3  应用3:政府治理

    政府拥有大量高质量的数据。依赖这些数据,可进行精确、及时的政府治理。近年来,在我国的一些大中型城市,已经出现一批利用交通监控、社交媒体、行人骑行等各种数据进行城市规划、城市管理的成功案例。

    政府治理不仅依赖自身各职能部门的数据,也使用来自于企业和社会的数据。这些数据的分享、使用需要在一个统一、有监管的平台上进行,区块链是实现平台的自然选择。与加密货币的去中心化不同,政府治理可能是多中心或者弱中心的,节点在一定程度上可被认为是可信的。区块链的架构、共识机制设计,乃至数据的存储方式、模型管理、查询和事务处理技术都需要面向政府治理进行裁剪和定制。

    4.4  讨论

    秉持“分类适用”的思想,可以看到,当前面向金融应用的区块链系统并非适用于所有领域。笔者认为,区块链技术在以下3方面值得进一步深入探索。

    首先,面向弱可信的弱中心或多中心的应用环境,可信数据管理系统架构是一个重要问题。很多关键任务应用都处在这样的环境中,且社会的组织架构本身以及政府职能部门监管要求,共同决定了绝对的去中心化系统的适用范围并不大。这就需要重新审视区块链本身的结构,研发更适合场景的系统。

    在多中心的架构下,华盛顿大学研发的对等网络[23]上的数据管理原型系统Piazza[24]是一个有益的参考。Piazza系统中,每个节点维护自身的数据;节点间数据模式可能不同;节点与邻居节点的数据库间维护着数据模式的映射;一个节点上的查询利用模式映射翻译后可在对等网络上传播,从而访问其他节点的数据。这一组织方式比当前区块链的节点数据全量备份更灵活。当然, Piazza的数据管理机制欠缺对于防篡改和事务处理的支持也很薄弱,还有大量工作值得探索和尝试。

    其次是系统的性能[16]。无论是分布式共识机制、事务处理,还是数据的存储组织、索引、查询乃至分析处理,区块链系统都有极大的性能优化和提升空间。而且几乎所有应用都对区块链的性能有较高的要求。

    最后,链式结构天然地保留了数据的历史记录,然而当前的区块链系统对回溯查询[22]的支持仍然薄弱,而回溯查询对于审计、监管等区块链应用而言又是必需的。因此,笔者认为实现高效、灵活的回溯查询机制对于拓展区块链应用场景具有重要意义。此时,回溯不仅指对交易历史记录的回溯,也包括对机器学习等数据分析处理过程的回溯。

    5  分享型数据库

    区块链部分地解决了金融应用中无中心的信任问题。在更广泛的应用场景中,如何在不依赖信用的前提下建立信任,是重要的研究问题。

    随着互联网技术的发展,越来越多的领域首先通过线上(online)数据共享,进而实现线下(offline)虚拟或物质物品的分享,以实现资源的合理利用和价值提升。这一过程在共享单车的迅速崛起并随之暴露大量的企业管理、政府治理、用户行为问题的历程中得到了充分的体现。共享单车等互联网应用的蓬勃发展说明我国在商业模式创新方面已经走到了世界的前沿,商业模式的创新能否转化为科技创新的驱动力则是一个国家创新能力的标志。需要发展新的数据管理技术来为企业的日常运营、城市的有效治理提供有力的支撑。

    能支撑新的数据管理需求的系统可以称为“分享型数据库(sharing database)”,它应能支持核心业务(mission-critical application),支撑分享经济业务模式(business model),甚至本身也是以分享经济的方式实现的分享经济时代的数据库。区块链已经展示了面向特定领域应用,设计实现这样的系统的可能性。但在更多的领域,需要类似区块链的分享型数据库系统解决可信数据管理的问题。

    分享型数据库应秉承“分类适用”的理念,与领域和应用紧密结合。与传统的数据管理系统不同,分享型数据库的系统形态将是多样的:对于涉及“人—财—物”的应用,提供完善的事务处理机制以及一体化的数据获取和管理;对于复杂数据的管理,提供结构化数据模型和模式的管理;对于涉及数据分析的应用,提供丰富的时序和回溯查询支持;对于涉及数据处理审计的应用,则在日志的基础上,实现事务、统计乃至机器学习算法处理流程和结果的理解和记录;分享型数据库的架构也与应用相对应,可能是去中心的,也可能是弱中心或者多中心的。

    信息化是业务发展和改革的基础,很多时候也是改革的先锋,甚至引领应用创新。笔者相信,与区块链促进了金融技术(FinTech)的演进一样,分享型数据库将伴随分享经济而快速发展。

    点击下方 阅读原文 即可获取全文

    作 者 简 介

    640?wx_fmt=png

    钱卫宁(1976-),男,华东师范大学数据科学与工程学院教授、博士生导师,主要研究方向为互联网环境下的数据管理、大数据管理系统评测基准、社交媒体数据分析、知识图谱构建与应用等。

     

    640?wx_fmt=jpeg

    金澈清(1977-),男,华东师范大学数据科学与工程学院教授、博士生导师,主要研究方向为基于位置的服务、数据质量、不确定数据管理、区块链等。

     

    640?wx_fmt=jpeg

    邵奇峰(1976-),男,中原工学院软件学院副教授,华东师范大学数据科学与工程学院访问学者,主要研究方向为大数据、区块链。

     

    640?wx_fmt=jpeg

    周傲英(1965-),男,华东师范大学长江学者特聘教授、副校长,数据科学与工程学院院长,主要研究方向为Web数据管理、数据密集型计算、内存集群计算、分布事务处理、大数据基准测试和性能优化。

     

    640?wx_fmt=jpeg

    《大数据》期刊

    《大数据(Big Data Research,BDR)》双月刊是由中华人民共和国工业和信息化部主管,人民邮电出版社主办,中国计算机学会大数据专家委员会学术指导,北京信通传媒有限责任公司出版的科技期刊。

    640?wx_fmt=jpeg

    关注《大数据》期刊微信公众号,获取更多内容

    展开全文
  • 【CSDN现场报道】12月7-9日,由中国计算机学会主办,CCF 大数据专家委员会承办,中国科学院计算技术研究所、中科天玑数据科技股份有限公司、CSDN协办的2017中国大数据技术大会(BDTC 2017),在北京新...华东师范大...
  • 2016年12月8-10日,由中国计算机学会(CCF)主办,CCF大数据专家委员会承办...华东师范大学数据科学与工程研究院院长周傲英大数据大会,第二天上午精彩继续,备受关注的数据库论坛在主持下华东师范大学数据科学与工...
  • 华东师范大学软件学院上机实践报告 课程名称:数据库应用 年级:15级 上机实践成绩: 指导教师:金澈清 姓名:陈伟文 上机实践名称:Sql Server 2008基本操作 学号:10152510217 上机实践日期:...
  • 华东师范大学软件学院上机实践报告 课程名称:数据库应用 年级:15级 上机实践成绩: 指导教师:金澈清 姓名:陈伟文 上机实践名称:高级sql语句实践 学号:10152510217 上机实践日期:2017/3/29...
  • 8月26日,星环邀请来自华东师范大学软件工程学院的博士生导师宫学庆教授带来《数据库前沿技术系列讲座》,分享数据库业内前沿发展和研究热点。现将宫学庆教授的培训第一讲内容:内存数据库的技术发展分享给大家。 ...
  • 数据库应用An Introduction to Database System华东师范大学East China Normal University 什么是数据库 数据库(DB)是长期存储在计算机内,有组织的,统一管理的相关数据的集合.DB能为各种用户共享,具有较小的冗余度,...
  • 本文作者宫学庆,是华东师范大学计算机科学与软件工程学院教授、博士生导师。 研究领域为数据库技术和分布式系统,主持过国家自然科学基金项目和多项企业合作项目,发表研究论文30多篇,曾参与交...
  • 译者简介朱君鹏,华东师范大学博士研究生,个人兴趣主要集中在:新型硬件(GPU、RDMA、FPGA等)在数据库中的应用,架构设计与并行计算。校对者简介崔鹏,任职于海能达通信股份有限公司哈尔滨平台中心,数据库开发高级...
  • [1].李国彬,赵丽娟,沈淑清等.SQL Server 2000 应用基础与实训教程.西安:西安电子科技大学出版社,2004.[2].程有娥.SQL Server 2000 数据库管理系统.上海:华东师范大学出版社,2007.
  • 数据观小编获悉,不久前,在中国大数据技术大会(BDTC)-区块链分论坛上,华东师范大学数据科学与工程学院教授、博士生导师钱卫宁发表了《区块链的五张面孔:一种可信数据库的观点》的主题分享。 区块链技术掀起...
  • 大数据管理系统评测基准的挑战与研究进展钱卫宁,夏 帆,周敏奇,金澈清,周傲英华东师范大学数据科学与工程研究院 上海 200062摘要:数据库评测基准在数据库发展历史中...
  • 译者: 朱君鹏, 李红艳作者简介Ryota Takizawa,Hideyuki ...译者简介朱君鹏,华东师范大学博士研究生,个人兴趣主要集中在:新型硬件(GPU、RDMA、FPGA、NVMe等)在数据库中的应用,架构设计,分布式系统,机器学习...
  • 12月9日下午的BDTC 2017的区块链和数据库分论坛上,来自华东师范、中科院、趣链、人民...华东师范大学数据科学与工程学院教授、博士生导师 钱卫宁 在互联网技术发展,新型应用层出不穷的大背景下,借鉴区块链在数...
  • 译者: 朱君鹏,陈河堆作者简介Naju Mancheril,来自卡耐基梅隆大学。这是一篇介绍在PostgreSQL中...译者简介朱君鹏,华东师范大学博士研究生,个人兴趣主要集中在:新型硬件(GPU、RDMA、FPGA)等在数据库中的应用,架...
  • 此次升级,华东师范大学将其中最为关键的数据库部分,迁移至富士通的PRIMEPOWER650服务器上,经过测试,系统在应用的高峰时刻仍然能够保证快速的响应时间,系统的资源使用也仅占用了60%。学校首先建立起公共数据库...
  • 译者简介朱君鹏,华东师范大学博士研究生,个人兴趣主要集中在:新型硬件(GPU、RDMA、FPGA等)在数据库中的应用,数据库系统,分布式系统,架构设计与并行计算。Qinghui.Guo,PG粉丝,DBA,负责公司Cloud DB的维护,...
  • 译者简介朱君鹏,华东师范大学博士研究生,个人兴趣主要集中在:新型硬件(GPU、RDMA、FPGA等)在数据库中的应用,数据库系统,分布式系统,架构设计与并行计算。Qinghui.Guo,PG粉丝,DBA,负责公司Cloud DB的维护,...
  • 2.华东师范大学软件学院,上海200062) (zhuzhenyi@hotmail.com) 摘要:针对传统的家具投标报价的繁琐性,实现了一种全新的家具辅助销售系统。该系统使用 AutoCAD2002平台,运用ObjecLARx和数据库管理技术,实现了...
  • 宋光旋-华东师范大学-窗口函数优化.pdf 曾文旌-阿里云-使用 PostgreSQL 去 O 的冰与火.pdf 孙鹏-英资教育-数据库设计中对JSON的使用.pdf 陈飚-Cloudera-Hadoop最新结构化存储利器Kudu.pdf 唐成-云徙科技-...
  • 完全内核,界面的改变,增加学生...慈溪市中学,慈溪市桥头镇中学,苏州立达中学,浙大模具培训学校,慈溪三山中学,慈溪中等职业技术学校,昆明理工大学,华东师范大学,慈溪市三管小学,慈溪市育才中学,育才小学...

空空如也

空空如也

1 2
收藏数 31
精华内容 12
关键字:

华东师范大学数据库