专属服务器_分布式数据库系统_好用

对象存储 虚拟云 浏览

小编:背景: 我们想回顾一下HANA侧车中当前的表分布,看看如果我们在同一节点上开始"分组"类似表,常驻报告/模型/查询是否会受到负面/正面影响。ECC中的许多复制表都是基于oltp事务的表

专属服务器_分布式数据库系统_好用

背景:

我们想回顾一下HANA侧车中当前的表分布,看看如果我们在同一节点上开始"分组"类似表,常驻报告/模型/查询是否会受到负面/正面影响。ECC中的许多复制表都是基于oltp事务的表,因此即使是基本报表也需要5-10个表才能连接或合并在一起。在对逻辑"分组"进行大量的"where used"类型调查之前,我们想对一个报表的所有源不在同一个节点上的开销做一些基本的分析,云服务器如何,表分配是由默认的循环分配处理的,这里还有一个通过Studio使用向导类型函数重新分配的选项。在进行任何更改之前,请保存当前的分发版本。

在这一阶段,大家可以在这里找到这个很好的参考文件,但是对于工作室链接等来说有点过时了,因为我不想在这里讨论所有相同的内容。

Hana中的表分布

我现在只关注一个模式,这是所有ECC表复制到的地方,所以让我们看看当前的配置如何匹配。

从上面看,02看起来承载了大部分表,所以不确定默认分发的工作效率。在任何情况下,还请注意04节点被保留为故障转移专用节点,目前没有分配任何表。

将特别关注前10名中的3个,

最初的问题是HF1在生产中没有查看任何表分布,因此让我们在Prod上执行以下脚本,因此,数据库架构师,我们可以同步HF1以匹配。

重新分发的语法

注意:端口是目标索引服务器的端口,而不是SQL端口。

实际的alter table语句会立即返回,因为在重新分发过程中会移动到表的链接,而不是物理表。您还将注意到,该表已从内存中完全删除,并且将加载=否。因此,在下次合并或访问时,它将需要一些额外的时间。

我们分析的一个简单计算视图

JEST是我们最大的表,它已经在HF1上的3个节点上进行了平均哈希分区。所以让我们用我们现有的。这些表基本上都位于3个不同的节点上。由于这种配置,我会看到任何显著的性能开销吗?

Qry1:

我们现在只选择设备编号,它应该删掉上面计算视图的右侧,而不是撞到分区的JEST表。

让我们看看VizPlan提供了什么,我确实希望看到一些基于当前设置的网络数据传输条目。

注意,上面提到了一些传输,但是与总体运行时间相比,开销相对较小。

Qry2:

虽然我们有表分配,云端大数据,但是让我们添加分区表,看看在VIZ计划中是否看到更多这些网络数据传输条目。我还将扩展没有where子句的查询,但保留top1000 stop子句。这毕竟是一个Perf框,云存储怎么用,我想看看是否必须移动大量的记录会增加网络数据传输的时间。

从上面我们可以看到网络数据传输的数量有所增加,但是即使有更大的卷,开销似乎可以接受,再次与整个运行时进行比较。我们还看到calc视图的两条路径现在都被执行,JEST分区被并行命中。

Qry3:

让我们看看将EQUI&eqz移动到同一节点是否会删除网络数据传输条目。

语句'ALTER TABLE ECC_报告.eqz移至"hf1hana02:37003"

在259 ms 793µs内成功执行(服务器处理时间:150 ms 915µs)–受影响的行:0

注意eqz不再驻留在内存中,让我们进行加载,这样在执行查询时就不会出现问题。

再次执行相同的qry1,让我们检查VizPlan,

如预期,云 数据库,Qry1 VizPlan中的网络数据传输步骤现在已经不存在了。

摘要:

所以我希望这个博客对于那些正在研究表分布、如何检查当前配置以及如何可能识别潜在问题等的人来说是一个开始。结果本身并不是非常引人注目或响亮,但希望这能引发更多的讨论。对于分区以及分区如何提高/降低查询效率,也有进一步讨论的空间。我在上面的查询中只使用了3个表,所以表的分布相对较小的影响可能会随着更大的表或涉及更多表的查询而增加

所以欢迎所有的评论或意见

文章来源:www.vmchk.com

 
你可能喜欢的: