我使用以下查询:
set use-result-cache false
set use-http-cache false
create or replace table settings@inmemorystorage
as
select '29676ec4-61b5-45eb-a5a3-6feffe03d1d3' sor_id
, '[[Exploded]]' exploded_signal_text
, '{res:itgen_eol_sales_order}' entity_name_singular
, '{res:itgen_eol_sales_orders}' entity_name_plural
from me
select ...
from settings@inmemorystorage stg
left
outer
join ExactOnlineREST..salesorders sor
on sor.orderid = stg.sor_id
left
outer
join ExactOnlineREST..salesorderlines soe
on soe.orderid = stg.sor_id
left
outer
join BillOfMaterialItemDetails bom
on bom.billofmaterialitemdetails_billofmaterial_item_id_attr_guid = soe.item
left
outer
join ExactOnlineREST..items itm
on itm.ID = bom.item_id_attr_guid
left
outer
join ExactOnlineREST..itemsread itr
on itr.code = bom.item_code_attr
where sor.orderid is not null
and itm.class_10 in ('A', 'D', 'M', 'S', 'Z')
从Exact Online检索数据。在我的测试环境中,它运行大约1秒钟,以在销售订单上应用物料清单爆炸(对于Exact Online的XML和REST API,大约有5次读取)。但是,在客户站点上运行超过15分钟。它似乎与检索物料清单中使用的物品(物品)有关;在我的测试环境中,大约有100个项目,而客户站点有250.000个项目。
但是,此查询用于交互式程序,应该在2.5秒内运行。
我尝试将itemsread和items结合起来限制检索的项目,但它们有两个表所需的不同字段。
如何使用大量数据优化此查询以更快地运行?
答案 0 :(得分:1)
问题出在第二个查询中:有许多项目,Exact Online的API每秒可能有300个项目的吞吐量。所以这已经永远不需要改变了。
有两种替代路线:
查询优化可确保在首次使用和后续使用时获得出色的性能和较少的资源使用。缓存的使用改善了第二次使用时的响应时间,但需要比优化查询更多的资源。
要优化查询,您需要指示优化器如何更正确地处理连接,因为默认情况下,Exact Online上没有可用的统计信息和参考数据。我会添加以下提示:
select /*+ join_set(soe, orderid, 100) join_set(itm, id, 100) join_set(itr, code, 100) */ ...
from settings@inmemorystorage stg
...
第一个提示join_set(soe, orderid, 100)
指示优化器将连接算法从散列连接更改为循环索引,以便在soe
(右侧)orderid
上有settings
的连接从执行路径中的上一步返回的最多100行。在这种情况下,将从itm
返回一行。同样适用于itr
和select /*+ ods(true, interval '7 days') */ ...
的加入。
对于大型Exact Online环境,这将确保在销售订单少于60行时始终进行5次查找。这通常需要1秒钟。
当您将PostgreSQL,SQL Server,Oracle或MySQL数据库配置为Invantive Data Cache支持数据库提供程序时,您可以将部分查询的结果存储在普通数据库中。当数据缓存仍然足够"新鲜"时,优化器会使用ANSI SQL自动查询此普通数据库。
例如:
{{1}}
告诉优化器在数据放入数据缓存不超过7天之前,将数据缓存用于所有Exact Online数据。当它超过7天时,它会创建一个新版本,将其存储在数据缓存中并使用它。
当您需要包含Exact Online中的近实时更改时,您必须配置数据复制。然后,它通过Web挂钩检索所有插入/更新/删除事件,并将它们应用于您的数据缓存。但是缓存仍然可能是30分钟,因为传播可能需要一些时间。
性能比没有缓存和没有优化要好得多。一般来说,250.000项的吞吐量将是1.000倍,因此与使用250项相比。鉴于Exact Online的典型页面大小为60,它将感觉为5 + 5 + 3 = 13 I / O,因此大约2,6秒,接近2.5秒的边界。
请注意,您使用的物料清单表将永远不会使用索引查找,因为此时没有可用的索引。因此,如果您在所有产品中都有大量物料清单,则必须使用数据缓存以获得合理的性能。