随着财务数据量的增长,企业为了获得更好的报表功能和分析能力一直在努力简化数据管理。 在近期出版的《SAP Simple Finance软件概述》一书中,Lob财务和SAP创新中心负责人Jens Krüger博士向读者介绍了SAP Simple Finance的HANA驱动应用的内部原理,这种应用就是为简化财务操作而设计的。 本系列文章节选自第三章:消除冗余。文中对SAP Simple Finance背后的核心理念之一(消除冗余)做了深度解释。
内存计算技术消除冗余数据 几十年来,为了达到足够好的性能,数据冗余已经被勉强接受了。基于磁盘的数据库系统迟缓的响应时间迫使我们不可能采用无冗余数据模型。……
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
随着财务数据量的增长,企业为了获得更好的报表功能和分析能力一直在努力简化数据管理。
在近期出版的《SAP Simple Finance软件概述》一书中,Lob财务和SAP创新中心负责人Jens Krüger博士向读者介绍了SAP Simple Finance的HANA驱动应用的内部原理,这种应用就是为简化财务操作而设计的。
本系列文章节选自第三章:消除冗余。文中对SAP Simple Finance背后的核心理念之一(消除冗余)做了深度解释。
内存计算技术消除冗余数据
几十年来,为了达到足够好的性能,数据冗余已经被勉强接受了。基于磁盘的数据库系统迟缓的响应时间迫使我们不可能采用无冗余数据模型。因为延迟和磁盘访问带宽比内存访问的差距不是一个数量级的,但是在内存中计算的代价是非常昂贵的。
但是,现在新时代已经来到了我们面前。内存计算技术从根本上挑战了根深蒂固的思路。在本文中,我们将展示SAP HANA如何在不影响性能的前提下去除冗余。
当今时代,内存计算做聚合是完全可行的。为实现在不破坏业务流程的前提下去除冗余,我们要在基于内存的系统中用内存中计算替换物化聚合数据,同时必须达到磁盘数据库系统中采用基于物化数据技术实现的性能效果,至少性能不比原来差。我们将要做的是对基于磁盘系统采用物化数据技术的方案和基于内存系统的内存计算技术方案之间做比较。
我们来仔细看一看。为了展示效果,我们将采用基于磁盘的系统,磁盘延时为10毫秒(即,访问磁盘随机位置要花10毫秒,也就是一千万纳秒)。相比之下,内存延时只有100纳秒(即0.1毫秒)。换句话说,数据库在一次磁盘访问的时间里,可以随机访问内存十万次。CPU单芯处理内存带宽每毫秒可以顺序读取4MB。在下面的例子中,我们选择8芯单CPU的一台服务器作为试验环境。现代服务器系统通常会配置多个CPU,每个CPU都拥有10芯以上配置,可以极大地增加处理能力。在我们的这个例子中,我们假定公司数据库中有1亿个会计凭证行项目和五万个客户。
在财务系统中,获得“特定客户当前月份总销售额”是很常见的一种聚合需求。在基于磁盘的系统中会利用物化数据,物化聚合数据针对这种分析会为每个客户每个月都建立元组,在分析查询请求时可以立即给出响应。因此,用户可以在10毫秒以后从采用物化技术的磁盘数据库中获得数据,且预期性能满意,前提是该数据库系统需要单次磁盘访问提取数据且忽略其他相关任何进一步处理。
在没有采用物化技术的内存系统中,聚合值并不是作为每个业务事务的一部分进行预先计算。这样一来,计算查询结果需要更多的步骤。然而,结果响应速度却更快了,我们后面会有展示。因为计算过程对访问数据库的应用来说是完全透明的,所以计算步骤不需要用户通知。更清楚地说,就是后续步骤序列会按该查询执行序列执行。内存系统的另外一个优势是内建的并行机制,它可以进一步对更复杂查询加速执行。这些步骤如下:
1.为指定客户查询所有会计凭证行项目
在列式表中,列代表了客户相关的行项目,存储在连续的内存块中。要识别指定客户的所有条目,数据库系统会扫描所有列并跟踪查询客户号条件。多亏了列式布局结构,这种全列扫描操作会以每毫秒每芯4MB带宽速度进行。SAP HANA内置压缩功能可以实现只比较把客户号压缩后的整数。因为有五万个不同的编号,所以对每个客户号的压缩只需要两个字节(216= 65,536 个不同值)。因此,1亿列客户行项目信息占用2亿字节,大约只有190MB。8核单CPU扫描这么大的区域需要6毫秒(190MB除以8核,再除以每秒4MB,结果不到6毫秒)。
2.做进一步查询
对于上一步骤的每个项,数据库有进一步查询的条件,比如按月查询。对于每个新增条件,都要查询相应区块。每个客户平均两千个行项,在所有数据位置都不连续的最坏情况下这就需要两千次随机访问。即便是这种情况,对于单核处理来说也只需要0.02毫秒(两千次访问乘以每次访问10纳秒,即2万纳秒)。
3.合计所有行项目的总销售额
所有相关项在前面的步骤中识别出来以后,数据库要提取每个项的销量并计算合计结果。同样,数据库要为了计算销量再一次随机访问每个块区位置,并多访问一次字典获得字典转码值。即便第二步骤没有排除进一步检索,一共也只需要4千次访问,单核处理只需要0.04毫秒。
对于整体响应时间来看,我们可以忽略步骤2和步骤3,因为它们对总体耗时影响不大。总体来看,在内存数据库系统中,对于指定客户本月销量在内存中计算大约需要用6毫秒,基于磁盘数据库的物化聚合数据的方案要10毫秒,显然内存计算系统胜出。因此,在本例中用内存计算替换物化方案是完全可行的。
如果是更复杂的查询情况,内存系统在内存中计算的优势会更加凸显;例如,简单查询只处理当前月份,而对于本年所有月份数据统计则需要访问12次磁盘获取物化数据的值,这些数据都是每月计算存储好的(除非该年的统计数据已经物化存储好了)。然而,基于磁盘处理的系统响应时间会相应增加到120毫秒,而内存计算方案只需要采用其它查询条件,其响应时间几乎维持不变,仍然只需要6毫秒。
我们已经通过凸显其益处展示了无冗余系统的可取性。此外,这些计算还表明其可行性是基于更快性能的内存计算而获得的。现在,获取快速而且稳定的访问时间是可行的,而在传统基于磁盘的系统来做则是相当昂贵的。基于缓存策略,基于磁盘的数据库不得不从磁盘获取数据,忍受较长的延迟和拥挤的带宽。与之相比,内存数据库不只提供更快速的性能,还能获得更稳定的响应时间。因为内存计算方案不像在基于磁盘的系统中那样,延时和带宽会因频繁操作需要多次往返磁盘提取数据而进一步损耗性能。
那么在下一篇文章中,我们就将详细介绍SAP Simple Finance软件如何建立无冗余系统。
系列文章:
深入理解SAP Simple Finance与HANA:消除冗余的必要性
深入理解SAP Simple Finance与HANA:内存计算技术消除冗余数据
翻译
相关推荐
-
2017年10月数据库流行度排行榜 与去年同期相比看点十足
数据库知识网站DB-engines更新了2017年10月份的数据库流行度排行榜,进入收获的季节,数据库流行度排行榜会有哪些变化?会给我们带来哪些惊喜呢?
-
2017年9月数据库流行度排行榜 SAP HANA名次下降遭“垫底”
数据库知识网站DB-engines更新了2017年9月份的数据库流行度排行榜。TechTarget数据库网站与您分享9月份的榜单。
-
在云环境和内部部署SAP HANA部署有何异同?
SAP HANA部署方案支持纯粹的本地部署,也支持云部署,如何选择方案可能有点令人难以掌握。
-
在HANA上实施SAP BW要做哪些准备?
在HANA上实施SAP BW可以帮助公司利用到HANA的速度和性能优势。不过,CIO及技术团队首先要注意一些关键问题。