ABAP CDS性能-多个关联的使用

2020-08-30 11:02发布

点击此处---> 群内免费提供SAP练习系统(在群公告中)加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)你好 我正在使用HANA上的E...

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


你好

我正在使用HANA上的ECC系统。 该系统中没有标准的ABAP CDS,但我为销售订单建立了自己的数据模型。

为简单起见,假设我有

-销售订单标题的ZI_SalesOrder视图

-销售订单项目的ZI_SalesOrderItem视图

-销售订单项目条件的ZI_SalesCondition视图(表KONV)

让我们专注于销售订单项目以及与条件的关联。 定义如下:

定义视图ZI_SalesOrderItem
 从vbap中选择
 vbak.vbeln上的内部连接vbak = vbap.vbeln
 vbap.vbeln上的内部连接vbup = vbup.vbeln
                 和vbap.posnr = vbup.posnr

 在$ projection.SalesOrder = _SalesOrder.SalesOrder上,将[1..1]与ZI_SalesOrder关联为_SalesOrder

 将[*]与ZI_SalesCondition关联为_Conditions
 在$ projection.ConditionId = _Conditions.ConditionId上
 和$ projection.SalesOrderItem = _Conditions.ConditionItem
 ... 

条件视图如下所示:

定义视图ZI_SalesCondition
 从konv中选择
 {
 将konv.knumv键作为ConditionId,
 konv.kposn键作为ConditionItem,
 将konv.stunr键作为ConditionStep,
 konv.zaehk密钥为ConditionCounter,
     konv.kschl作为ConditionType,
     konv.kwert作为ConditionValue,
     konv.waers作为ConditionCurrency,
     案件
         当konv.krech ='A'时div(konv.kbetr,10)
         否则konv.kbetr
     以ConditionAmount结尾
     案件
         当konv.krech ='A'时强制转换('%'为abap.char(3))
         否则konv.waers
     以ConditionAmountUnit结尾
 }
 其中konv.kappl ='V'和konv.kinak =''
 

现在,在此数据模型之上,我创建了一个在Fiori应用程序中使用的消耗视图。 在此视图中,我需要显示项目和一些条件值。 例如,我在一栏中需要MWST条件值。

这就是我使用关联的方式:

//税
 Item._Conditions [1:ConditionType ='MWST']。ConditionAmount作为TaxRate,
 Item._Conditions [1:ConditionType ='MWST']。ConditionAmountUnit作为TaxRateUnit,
 Item._Conditions [1:ConditionType ='MWST']。ConditionValue作为TaxValue,
 

一切正常...但是速度很慢。 非常慢。 在生产环境中,仅显示一个包含4个项目的销售订单可能需要8到9秒钟。

我使用ST05 tcode获取跟踪计划,并在Eclipse中将其打开。 我没有使用此工具,但我了解数据库会读取所有条件类型为MWST的记录,然后将其与所选销售订单的条件ID进行比较,而不是通过逻辑方式搜索,而是从 销售订单,然后在KONV中获取相应的记录。

是什么让我这样想:

如您所见,条件表中选择了15905812条记录! 如果我看一下细节:

我可以看到所有这些都是针对KONV条件的,如果它来自条件ID(KNUMV),我将获得超快的速度。

我的问题是:对此我该怎么办? 在CDS视图或数据库中我可以做些什么吗?

我在CDS中尝试过,但是没有改变:

 Item._Conditions [1:ConditionId = ConditionId和ConditionItem = ConditionItem and ConditionType ='MWST']。ConditionAmount作为TaxRate,

真的需要您的帮助...谢谢。

(14.1 kB)
7条回答
ZJXianG
2020-08-30 11:07

根据提供的信息,不可能正确理解是什么原因导致性能下降。

我看到的是这样的结果:

  • "在表上搜索" 在KONV上花费275ms包括所有四个相等的谓词(MANDT,KAPPL,KSCHL和KINAK)
  • 将这四个谓词组合起来只能过滤出最少的记录份额(15,947,186-15,841,828 = 105,358-> 0.66%)。
    对于实际手段,这些谓词不会过滤KONV表
  • 大量数据将进一步传递给处理树。 在ZI_SalesCondition的投影列表中,为ConditionAmount和ConditionAmountUnit执行了相当昂贵的每条记录计算。
    这导致大量数据的实现(请参见创建临时表计划运算符)

基于此,最可能出现的顶级查询 不能提供有效的筛选条件,该条件可能会减少数据量(对于客户端查询结果集而言,近16 Mio行通常太多)。
此外,应该检查是否最需要查询的列实际上是计算得出的列(例如,如果查询是简单的SELECT * FROM ...,那么仅指定相关列会很有帮助)。

如第一句话所述,这是一项不完整的评估,因为缺少许多信息(顶部查询,解释计划,完整计划即跟踪,完整CDS源,表统计信息...) 但是,从列出的观察结果中应该清楚的是,数据模型的"性能"不仅取决于该模型的设计方式。

相反,它是基于

顶部查询+数据建模+表中的数据

希望仍然有帮助。

一周热门 更多>