更新日期:2018年5月15日
此博客已过时
请查看此博客了解最新消息
晚上好,各位网友,
想到今天,SAP HANA与旧车有什么共同之处?
换一种说法,一辆普通的现代家用车有什么SAP HANA没有的?
请继续阅读并找出答案。
我的第一辆车,当我在1990年开始驾驶时,已经三十岁了!可以用前面的手柄启动。
汽油表。我们都知道这一点,从旧的和新的汽车,每辆车都有一个燃油(或汽油)表,云服务器品牌,所有的汽油表告诉我们在任何时间点我们还有多少汽油。
这是老式汽车上的汽油表的样子:
这是现代汽车上的汽油表的样子:
在过去的60年里,汽车上的汽油表没有太大的变化,它仍然
做同样简单的任务,在任何时候告诉司机(管理员)还有多少汽油容量。
在过去,在一辆只有汽油表的汽车上,司机(管理员)必须用经验和知识来理解,
从剩余的汽油中(我们称之为这个容量),根据目前的驾驶方式(我们称之为使用方式),
汽车能继续行驶多远直到汽油用完(继续行驶的能力)?
然后,管理员(司机)必须弄清楚在哪里和什么时候加油(获得更多的容量),以便在汽车耗尽汽油之前获得更多的汽油容量。在这种情况下,汽车将停止运行,管理员(司机)将不得不带着一罐汽油沿着道路行走。
这在过去并不少见,新零售企业应用中心,今天仍发生在一些人身上。
那么这与SAP HANA有什么关系?
在InMemory数据库出现之前的日子里,如果一个数据库的容量(磁盘)用完了,Unix
管理员只需运行几个命令,瞧,会有更多的磁盘空间,更多的
数据库容量。因此,基于磁盘的数据库中的容量监控设置为
在剩余可用容量为30%、剩余可用容量为20%、剩余可用容量为10%时生成警报,
每个剩余可用容量的阈值都有足够的时间来扩展磁盘空间。
这类似于90年代的汽车,数据和大数据的区别,因为油箱的燃油不足而亮红灯。
提醒驾驶员(管理员)加油。
在基于磁盘的数据库时代,我们不需要知道有多快数据库
正在增长,因为我们能够轻松快速地添加更多磁盘容量。
现在回到SAP HANA。
在SAP HANA世界:
。容量为内存/RAM
。而且内存/RAM不像磁盘空间,内存/RAM是由块或服务器节点组成的,因此在一定程度上比磁盘
有限得多。更令人担忧的是,扩展内存/RAM或ServerNodes并不像扩展磁盘空间那么快和容易,如果需要购买新的ServerNodes,它的交付周期可能长达数月!
因此在SAP HANA世界中,物联网智能水表,我们需要了解:
。我们还有多少剩余的存储容量-经典的老式汽车汽油表
。我们当前的内存使用率基于历史增长模式–我们每月消耗多少内存,gb/月
。从以上两项来看,在汽油/内存耗尽之前,以当前的增长率gb/月可以运行多少个月
。既然我们知道添加更多内存容量需要多长时间,不管是内存模块还是节点,那么我们需要在什么时间点触发基于当前使用量、剩余容量和增长率的容量顺序?
. 然后试着找出有不同使用率和增长率的多个租户的地段
但我们没有SAP的任何工具来做到这一点!是的,我们有HANA 2.0驾驶舱,但它太小了。
现代汽车仪表板
这些参数,现在几乎是现代家庭汽车的标准设备,我们有:
。汽油表告诉我们还有多少汽油。这些分析告诉我们,基于对驾驶风格的历史使用分析,当前的使用量是多少,单位是升/100公里或英里/加仑
。预测分析告诉我们,根据目前的使用方式和历史消耗量,我们可以行驶多远才能用完汽油
看起来是这样:
然后,再往前一步,如果我们真的幸运,我们有一个导航系统连接到预测分析,它会告诉我们下一个加油站在哪里在我们的汽油容量范围内:
那么SAP HANA与旧车有什么共同点,在今天的SAP HANA中,管理员几乎只使用燃油表来了解HANA系统中有多少可用内存容量。
我们需要SAP使SAP HANA管理员工具达到我们在现代汽车中习以为常的标准。
我们需要一个仪表板来告诉我们:
。当前在节点级别和所有节点上有多少可用内存容量
。当前内存消耗率是多少,按租户、按节点和跨所有节点,基于过去几个月的历史增长率(GB/月)
。我们需要知道在当前消耗率下,当单个节点和跨节点的HANA系统将出现容量不足时,以当前消耗率(GB/月)为单位,在我们撞墙之前,我们还能运行多少个月