更新日期：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/月）为单位，在我们撞墙之前，我们还能运行多少个月