使用 PutDatabaseRecord 处理器进行非常慢的更新答案

【问题标题】：Very slow UPDATE with PutDatabaseRecord processor使用 PutDatabaseRecord 处理器进行非常慢的更新
【发布时间】：2021-07-16 11:06:03
【问题描述】：

我有 2 个PutDatabaseRecord 正在写信给Oracle DB。

这是架构的一部分：

那里的红色方块不是错误，而是信息消息，因此我将处理器置于 INFO 模式。所以它讲述了获取模式，以及使用 SQL 更新命令“提交因为批量大小”。

问题是，其中第一个：ml_task，在几分钟内处理了数百万条记录，但另一个：ml_sales - 数小时内有 1000 条记录堆栈...这两个堆栈都在晚上，当 DB每天都加载很多。

在同一时刻，update goods.ml_[name] set load_date = sysdate 语句通过 SQLDeveloper 接口花费相同的时间 - 对于 ml_task 和 ml_sales。晚上大约需要 10 分钟，白天大约需要几分钟。

他们都使用相同的池服务。

这是服务底部的配置：

两个处理器具有相同的配置，除了表名和更新键。

我尝试将Max Batch Size设置为零，它没有影响。

配置的两个处理器在一个线程中运行，但我尝试配置 10 个线程 - 没有影响。

此外，与数据库的连接完全不缺，我有大约 10 个处理器，每个处理器都使用一个线程，所以 50 个连接，我认为就足够了。

他们正在处理大约 500 万条记录。

这是ml_task的JSON：

[{"DOC_ID": 1799041400,"LINE_D":694098344,"LOAD_DATE":"16-Jul-21"} ... ]

这类似于 Nifi 对ml_task 的更新：

update goods.ml_task
set load_date = sysdate
where doc_id = ? 
and line_id = ?;

这是桌子：

Name          Null?    Type   
------------- -------- ------ 
DOC_ID        NOT NULL NUMBER 
LINE_ID       NOT NULL NUMBER 
ORG_ID        NOT NULL NUMBER 
NMCL_ID       NOT NULL NUMBER 
ASSORTMENT_ID NOT NULL NUMBER 
START_DATE    NOT NULL DATE   
END_DATE               DATE   
ITEMS_QNT              NUMBER 
MODIFY_DATE            DATE   
LOAD_DATE              DATE

这是ml_sales的JSON：

[{"REP_DATE":"06-Jul-21","NMCL_ID":336793,"ASSORT_ID":7,"RTT_ID":92,"LOAD_DATE":"16-Jul-21"} ... ]

ml_sales的请求如：

update goods.ml_sales set load_date = sysdate
where nmcl_id = ?
and assort_id = ?
and rtt_id = ?
and rep_date = ?;

还有桌子：

Name        Null?    Type       
----------- -------- ---------- 
REP_DATE    NOT NULL DATE       
NMCL_ID     NOT NULL NUMBER(38) 
ASSORT_ID   NOT NULL NUMBER     
RTT_ID      NOT NULL NUMBER(38) 
OUT_ITEMS            NUMBER     
MODIFY_DATE          DATE       
LOAD_DATE            DATE

ml_sales 更新如此缓慢的原因是什么？

更新

我把所有的电路都放到STOP，除了有问题的电路，我把所有的会话都提交到SQLDeveloper...结果是一样的...很长...

更新

如上所述，我实际上将ml_sales 表复制到了其他方案，这并没有影响结果。

【问题讨论】：

作为测试，您能否将 ml_sales 表复制到，假设为 ml_sales2 并针对它运行该过程？更新需要多长时间？
您有 1 个线程按顺序写入 5m 条记录……这会很慢。 NiFi 专为并行性而设计 - 增加并行写入数据库的节点和线程的数量。如果增加并发任务的数量没有影响 - 它实际上是否产生了多个线程？节点是否被过度使用？数据库是否被过度使用？
ekochergin - 我做到了，我将表复制到我的架构中，但并没有提高速度。
Sdairs，我会做的，但现在我尝试仅获取数千条记录，除了有问题的流程外，我停止了所有 Nifi。
您的 where 子句中的列是否有索引？

标签： oracle apache-nifi

【解决方案1】：

我猜Oracle中缺少索引存在问题。我让我们的 DBA 检查 DB 端的问题，他们修复了它，现在 UPDATE 的工作速度与 ml_task 表一样快，但不幸的是我仍然不知道到底是什么问题，因此 DBA 离开了职业。所以，很可能是索引问题。

【讨论】：