技术开发 频道

甲骨文与DTCC首“约”秀数据库技术创新

  【IT168 专稿】本文根据【2016 第七届中国数据库技术大会】现场演讲嘉宾吴承杨老师分享内容整理而成。录音整理及文字编辑IT168@杨璐 【微信搜索DTCC2014,关注中国数据库技术大会公众号】

  嘉宾简介

甲骨文与DTCC第一次约会

  甲骨文公司副总裁及中国区技术产品事业部总经理

  吴承杨,2010年加入甲骨文公司,现任公司副总裁及中国区技术产品事业部总经理。拥有25年的IT从业经验。在加入甲骨文公司之前,曾在惠普,戴尔和DEC 担任重要职务。获得计算机硕士学位以及马斯赫里赫特学院的MBA。

  正文

  这是第七届数据大会。这也是甲骨文第一次参加。

  三年前大家都在去IOE的时候,甲骨文怎样生存?三年后的今天,甲骨文依然还在, 再次印证了IE好去O难舍。去IOE教会了甲骨文如何贴近用户。

  首先我想说甲骨文今天是一个充满活力、充满新技术的公司。

  作为用户来讲,今年主办方的题目非常好,数据就是未来。对用户来说数据实际上是非常重要的。

甲骨文与DTCC第一次约会

  我们先从可靠性谈起。大家也知道甲骨文有一个叫RAC的技术。RAC技术的存在已经二十年,老的技术还有意义吗?至少可以讲三点:

  今天中国最大的银行之一,在去年刚刚把四个节点的RAC作为他的一个标准。第二点是中等银行,中等银行今天来讲可能刚刚上RAC。在中国比较少看到是基于8个节点的RAC?我可以说90%的是四个节点的RAC已经够了。既然四个节点的RAC是肩并肩的去做、手挽手的去做,为什么不去用。

  技术新老不是问题,而是对用户是否有意义。软件上你更愿意使用一个经过很多人使用过的还是愿意使用一个没有人使用过的,我想这是不言而喻的。

甲骨文与DTCC第一次约会

  所以我觉得从RAC来讲,其实你也知道,在今天来讲四个节点在中国已经可以解决很大的问题。别人问我,有了RAC以后,就够了吗?不够,除了你们数据库的企业版以外,还需要选购什么数据库选件?我第一个推荐的不是RAC,我第一个推荐的是ADG,为什么推荐这样一个产品呢?在座的各位都是数据方面的专家,我觉得最重要的方面是要让你晚上睡得着觉。什么叫晚上睡得着觉? 当你今天来讲一台机器出问题的时候,你要确保另外一台机器能够把所有的数据备份。这就能睡得着觉。

甲骨文与DTCC第一次约会

  你不要说两地三中心大概三千多米以外切换,我只说如果你这台机器出问题,是不是在另外一个机房、另外一栋楼里面,你可以把系统自动切换过来?如果你能切换过来我觉得你可以放心地去休息。但如果你没有做到的话,我觉得是有风险的。

甲骨文与DTCC第一次约会

  在ADG的同步模式下,ADG的先前的版本只能做到在短距离的同步容灾,比如十公里、二十公里之内可以进行无缝切换。ADG的新功能 Far Sync可以实现远距离的数据同步,可以实现性能和高可用性的双提升。如果你基于ADG技术去做整个的容灾,就会很方便。

  大家可能说容灾不应该是存储公司解决吗?如果存储公司做了容灾以后,能确保你的灾备点能够让数据自动起来吗?一个很重要的问题在存储容灾是基于存储的镜像复制,并不能保证数据的逻辑完整性。结构化的数据库数据与一般的非结构化数据文档相比有极大的差异,是不能简单的用基于存储、或者数据块镜像复制、或者快照技术进行复制备份的。数据库数据的备份,必须在物理数据被复制的同时,保证其逻辑的完整性。 基于存储的解决方案,不会去校验数据。如果源端有数据坏块,损坏的数据块也会被复制到目标端。 当你源端的系统中断,容灾系统接管数据库服务,启动时才发现相关数据块有问题,容灾中心也无法启动。我觉得这点可能大家在座的专家都是非常清楚的。

  所以说如果是基于数据库级别的容灾就不同了,在ADG中无论主数据库或备用数据库上何处发生物理块损坏,都能自动进行修复,从而防止为用户提供的服务出现中断。备用数据库既可以用于报表库、查询库也可用于灾难恢复。 这种做法能够增加可用容量,通过读写分离分担负载改进响应时间,并在利用物理复制的简易性的同时,提高备用系统的投资回报 (ROI)。

甲骨文与DTCC第一次约会

甲骨文与DTCC第一次约会

  所以未来分库分表一样,有更简单的方法,用甲骨文自动的分库分表技术。而且好的地方在哪里?未来可以让你在你的本地和云上打成一片。可以某一部分放在本地,另外一部分放在云上。

  所有这些东西我们把这些放在一起,我们说它帮你实现可靠性。

  第二个问题是快速

甲骨文与DTCC第一次约会

  快速的一个问题在于什么呢?如果今天你的系统慢,第一点要考虑的可能性、要判断问题在什么地方,问题的存在很可能是在数据库。

甲骨文与DTCC第一次约会

  解决的方法,有一种是去修改你的表,对他进行分区,这种方法是一种非常好的方法,通过分区把大表进行拆分,并行访问,去提高访问性能。

  如果说今天你的数据库 系统比较慢,解决方案里要改什么?但是问题在于是说你的需要修改的内容,并不是所有的DBA都能解决,在不调整的情况下,怎样能够让数据库跑得更快呢,答案是可以的。

甲骨文与DTCC第一次约会

  首先是内存技术。In- Memory 内存数据库是甲骨文数据库选件。大家一听说选件是不是就会觉得要差一点?其实不然,因为选件要插在主体上。主体不需要改变,在整个数据库不需要再改变的情况下插入选件就可以得到那个东西。

甲骨文与DTCC第一次约会

  为什么能做到这一点?因为甲骨文在in-memory 选件中数据以行和列的方式同时并存在内存中。因为大家知道很多的时候在做数据分析时,每秒都要分析几千行、几万行。这时候需要列。但如果你要做随机查询的时候就一定需要行查询。这是最基本的一点。很多时候你会发现有些机器用于分析、有些用于查询。是分开的。但是能不能混在一起呢?所以你可以发现数据库在划分时是按照两种方式划分的, 一种是行方式存储数据的事务处理型数据库、一种是列方式存储数据的数据分析型数据库。

  追求永无止境。很多时候不仅仅是现有数据,甚至希望把历史数据能够查询。因为现在存储已经不是很贵了,为什么不能实时查询历史数据呢?这时候你会用到什么?数据库在芯片上的技术。这个对你有什么好处呢?你可以看到它每秒钟可以扫描十亿行。怎么做到的?因为我们在芯片上安装了32个核的CPU,内存采用了查询加速引擎技术,从数据库查询接管了某些特定数据搜索功能,大大加快了数据库查询的执行速度。

甲骨文与DTCC第一次约会

  所以把这些硬件加速技术和甲骨文内存技术放在一起,你可以得到的数据库的加速,几乎可以忘掉你需要单独存储。接下来以后可以发现我们讲了两个方面,大家会觉得甲骨文很贵,说甲骨文的技术就是贵。但是我想说的一点,今天我们的技术里可以支撑什么?一个根数据库上可以支撑四千个可插拔数据库。

甲骨文与DTCC第一次约会

甲骨文与DTCC第一次约会

  关键问题不在于你选择贵,而在于如何使用。使用得好可以做得非常出色。这里有一个案例叫UBS银行,这个指标是通过把数据库整合,它可以把整个物理服务器台数从3300下降到187。那你可以想象你的成本节省多少。物理服务器从三千多台变为一百多台,数据库使用的CPU 核数36388个变为1万个,大大节省了数据库许可证数量,其实是节约了成本。

甲骨文与DTCC第一次约会

  今天很多用户都有这样一些疑问,今天云时代已经到来了,DBA还有发展吗?我说当然有发展。因为你还有很多的事情。

  那么安全性的问题,我觉得这件事情很重要的是要跟大家讲,不要等到有安全性问题出现以后才觉得安全很重要,亡羊补牢永远不解决问题。我们现在看到的问题是要说什么?其实如果你看到一个数据库,Oracle能够做到安全,帮你监测安全,你是不是觉得很放心呢。这里我就不每一项安全内容都去讲。但是我可以告诉大家一点,今天所谓数据库安全和所谓网络防火墙完全是两回事。

甲骨文与DTCC第一次约会

  举一个简单的例子来讲,如果你认为家里的防盗门是网络防火墙,数据库的安全就是家里的保险箱,用于在你家里存放你的存折,是存放你的存折的最后一道防线。 你可以进防盗门,但是你要知道80%的数据安全问题是来自于防盗门内部。所谓内部的门。你要确保你的保险箱的安全。

甲骨文与DTCC第一次约会

  今天在关系数据库上还有非常大的发展。当然我们也会谈大数据和智能分析。我这里举一个简单的例子,某国有大型银行,我们帮他做的一件事。大家到银行以后都会到排队机上取号,取号以后你得等待。如果你不是VIP的话,有时候要等一个小时才能叫到你的号,这是非常痛苦的事。这个时候我们就帮助银行做一件事,在后台会在你取号的纸条上给你推荐你所谓的理财产品。就这么简单。当然你是VIP用户,大堂经理会拿着他的Pad过来,先生您好,您今天过来了,您前面还有两位,我给你介绍一下吧。因为在你取号的时候,我们会同时把你的信息推荐给大堂经理。

甲骨文与DTCC第一次约会

  就这么简单一件事,大家知道就是在排队机上,推荐成功率由0.2%上升到8%,成交金额是90亿。这后面都是基于Oracle的大数据分析技术来实现的。你可以看到这就是它的路线图。

甲骨文与DTCC第一次约会

  大数据今天能做什么?什么叫探索的过程?大数据为什么要去探索,如果你有很多数据以后,我们会给你一个探索的工具。今天很多人会说,如果做数据的时候我需要先做一个数据模型,但是我的问题在于当你把数据模型做出来,很可能你的形式已经发生了变化。

甲骨文与DTCC第一次约会

  那有什么办法能够让你尽快地做出来呢?应该是探索的方法。如果探索的方法大家可以理解的话,那么你今天如果要查新数据,当然今天国内不能有谷歌,那你一定会用百度,你先会放关健词在上面。关健词之后有心理逻辑,我今天要查找一套朝阳区的房子,就会找有什么朝阳区的房子,然后就找有什么评价,然后就找有没有什么排名。

甲骨文与DTCC第一次约会

  这个过程是什么?这个过程就是探索。你今天借助的工具是什么?你借助的工具是所谓的搜索引擎。但是甲骨文会给你一个比搜索引擎更好的探索方式,会把你所有要求的这些东西、这些想法通过这个都呈现出来。

甲骨文与DTCC第一次约会

  数据库最大的挑战在哪里?最大的挑战,数据库我一直认为是小众,因为它相对来说比较底层。这点我相信大家清楚,我是学软件的,越是底层的越复杂。数据库毕竟是比较小众的。但是我们希望它比较简单的。那么怎么办?你希望它比较简单,你去找个保姆就可以了,你请一个钟点工帮你料理一切不就解决了吗?就是这个概念。

  一个月前我和一位甲骨文美国来的BD交流。我问他一个问题,今天美国的用户接受你们的概念到了什么程度?他告诉我他开过一个重要客户研讨会。这个会基本上每年都开一次。两年前说你不用跟我们讲,你就讲最新的技术,内存技术等等就可以了,我们对这些感兴趣。

  然后今年他说两个星期以前又开过一次会,这些公司是非常非常大型的公司,他们说你们不用讲产品,你跟我讲甲骨文的云布置。他说我也很吃惊,所以我是想分享给大家的点就是,其实今天云不管是你喜欢还是不喜欢,它已经成为一个趋势了。

甲骨文与DTCC第一次约会

  在不久的将来相信大家会慢慢把大多数的东西都转移到云上。我相信这一点。

甲骨文与DTCC第一次约会

  那么今天来讲是混合云,但是一定要相信今天云的发展是势在必行的。那我相信在中国整个互联网+某种程度是应对了这个。今天的架构和应用很重要在于什么?很重要一层是在于平台上。平台是什么?我的重要性在于它是衔接着你的架构。如果没有平台层你可以想象一点,你怎么样能够让数据移动。如果说你今天来讲是说,我在本地的话都不能把数据移动,那你怎么能指望在云上进行移动呢?其实我觉得平台是非常非常重要的。而今天大多数时候你会发现,绝大多数日常东西都是在结构上和应用上。

甲骨文与DTCC第一次约会

  很多云公司都是在架构上。甲骨文今天做的东西最重要一点就是甲骨文的三层Oracle Cloud,甲骨文三层全部都是,因为我们从本地技术就是提供了这些。那么你可以看到说,我其中一个产品在平台上,今天来讲你有很多日志文件,今天日志文件大家都不会管它。唯一是当你系统出问题你会把它调出来、发给它,然后让它去回应问题。但是不要忘了,今天所有的日志不管应用日志还是系统日志,数据库等等这些,是很有价值的。

甲骨文与DTCC第一次约会

  甲骨文基于这些日志文件我们提供一个OMC Log Analytics,去帮你去做分析。分析什么呢?第一帮你分析你的运维管理好不好 ,第二甚至于可以帮你分析今年你IT上的投资,这是CFO最愿意听到的,核算嘛。因为CFO最怕听到的是说,CIO跟他说对不起我一定要投,一千万。那你分析过一千万的投资是对还是不对呢,它会帮你分析,甚至会帮你规划明年IT的预算。因为很简单,你想想这么多系统里CPU利用率只有20%、30%,你就知道其实整个空间不需要改善,甚至不需要买数据库,只要做整合就可以了。

甲骨文与DTCC第一次约会

  你会发现一点,甲骨文会帮你一件事,你唯一要做的一件事就是要把你的日志文件上载。你只要做一件很简单的事,只要把你的日志文件上载,因为我在后台,有几百台、上千台加上模型去帮你分析。这是很简单,你可以找一个钟点工帮你做了。

甲骨文与DTCC第一次约会

  当然甲骨文的云很重要一点在于甲骨文的本地怎么做,在云上也怎么做。这带来一个好处,你既能上也能下。今天90%的云是你只能上不能下。但是甲骨文的云是可以让你上去,同时也能下来。因为两个是一样的。因为结构一样、产品一样、定位一样。这是对你的好处带来的是说,甚至于可以把本地和云,整个一个平台上,30%做在云上、70%做在本地。甚至你点点鼠标可以把一个应用迁移到云上,或者从云上迁移到本地。

甲骨文与DTCC第一次约会

  所以你会发现云这块真的有很多东西。

甲骨文与DTCC第一次约会

  的确云对我们每一个人来讲非常重要。最后我想总结一下,我觉得其实今天刚才说了我们讲两点,第一我们每年都会高调报道一下,确保大家可以看到甲骨文。第二我想跟大家讲甲骨文有很多新技术,甲骨文今天来讲全面转到云上去了,是云的公司。Oracle有很多新技术,简单来讲像数据库与芯片的集成、Oracle的内存技术等等,这些新技术我都会和每一个朋友去分享。

更多相关技术交流请扫码关注:甲骨文数据库技术官方微信公众号

甲骨文与DTCC第一次约会

0
相关文章