基于SAP HANA SPS 12（HCP试用版）

当Jody Hesch最近向我发送一封关于HANA问题的电子邮件时，他收到了每个人在发送关于HANA问题的电子邮件时收到的信息。这个回复是

我没有放弃我个人与盖戈凯的斗争，这是日常生活中的样子。

你可能会说这个回复很粗鲁，但事实证明，大多数人都很容易接受这个问题，并设法将他们的问题复制粘贴到某个论坛上-而改变文化总是有点痛苦…*滴滴**滴滴**滴滴*

和其他许多人一样，中国云，Jody设法把他的问题贴在这里供大家看、读和讨论：手动管理Delta Merge

当我在做尽职调查时，对照HCP试用HANA实例（SPS 12.04）检查我自己的想法，云估价，整个解释和示例变得比什么都好一个简单的答案，这就是为什么你现在读到这是一个博客文章的格式。Jody的问题是"如何手动处理delta merge使数据加载更快？"为了回答这个问题，我设置了一个小测试用例：

我们这里有一个简单的表和一个数据加载模拟。数据通过UPSERT命令被插入或更新，如果参数为\u commit=1，则在外部循环的每次迭代后都会进行提交。两个循环结束后，代码以秒为单位打印运行时，并从系统视图中选择一些统计信息。

接下来，我运行了三个实验。

前两个实验使用SAP HANA自动合并功能，HANA决定何时执行增量合并。第三个遵循sapbw用于数据加载的方法：自动合并被禁用，目标表在所有数据加载后被合并。

很容易看到，整个过程运行了386秒，并在delta存储中创建了总共505.101个记录版本。请注意，在此加载期间没有发生增量合并。这是因为我们从来没有提交过事务，delta合并也不会将打开的更新事务"重新定位"到新的delta存储区。

这里我们看到，在提交之间，整个过程只花了349秒。由于我们在两次之间提交了事务，所以自动合并有机会处于活动状态—而且几乎每分钟（5次）都会这样做。

现在，为什么这个变体总体上要快一点？查找当前活动记录版本的努力随着增量存储中版本的数量而增加。由于自动合并介于两者之间，这个数字一直保持在100.000版本以下，而第一个版本必须面对越来越多的版本才能在100.000和505.101之间进行检查。

最后，数据加载的版本与sapbw的方法类似。我通过

禁用了自动合并并再次运行测试：

325秒，大淘客网，这是最快的运行。查看手动增量合并所用的时间，我们发现它仍然比自动合并示例的最后一次增量合并要快。

这是–再次–因为现在表中的并发记录版本要少得多。注意，云服务器比较，MERGED泳DELTA泳RECORDS显示已从DELTA移动到主存储器的有效（已提交）记录数。如果我在提交之前更新同一条记录一百次，那么我只会将一条记录合并到主存储中。

现在，为什么在这种情况下我们会看到更好的性能？

为了说明加载期间的资源使用情况，请参见下图：

在第一种情况下，我们看到增量存储的内存使用量以及UPSERT的CPU使用量随着时间的推移而增加。最后一次提交完成后的某个时候，会触发自动合并，从而导致额外的CPU和更多的内存使用。结果是一个相对较好的压缩表（最后一个蓝色小方格）。

请注意，在整个过程中，未提交记录版本（橙色小方格）的数量都在增加。

使用第二种方法（commits in between and automerge on），我们可以看到在加载期间CPU和内存的使用保持适度。只有在执行合并时，内存和CPU使用率才会增加，整个进程必须等待合并切换到delta2才能继续。

这里值得注意的是，生成的表很容易大于其他方法生成的表大小。这是因为列压缩算法是在第一次delta合并期间确定的，不容易更改。这可能导致这样一种情况，即压缩算法是在不代表总数据的数据子集上确定的（考虑按顺序加载带有时间戳或日期的数据–第一次合并可能只看到一个特定日期）。

对于最后一个选项，我们看到的模式与第一种情况非常相似。这里唯一的区别是，最终合并是手动触发的。

因此，禁用自动合并和定期提交后，我们可以得到最好的结果：

由于增量合并而没有等待由于大量过期的未提交记录版本，运行时没有增加良好的压缩表（因为压缩优化可以在整个数据集上工作）。

只要结果的增量合并可以在可用内存中完成，就可以很好地工作。即使需要卸载其他内存结构以允许delta合并发生，在加载过程中也只能发生一次而不是几次。sapbw使用"智能合并"，而不是手动发送一个

来发出执行增量合并的硬指令。这里的想法是，考虑到当前的内存统计信息和合并决策函数，应用程序不需要强制delta merge让HANA评估是否允许合并。

使用这种灵活的方法，应用程序不需要关心如何决定何时进行合并的细节，但是仍然可以触发HANA来处理这个问题。