SQL Server join或Pentaho Spoon查找?

可能更适合dba.stackexchange.com。但我认为数据库引擎将更快地执行这项任务,因为a)它可以使用索引和表统计信息优化对所有相关表的访问;b)您摆脱了ETL工具和多个数据库查询带来的开销。Pentaho PDI单独处理行,因此对于来自表输入步骤的每一行,每个查找步骤都有一个SQL查询。

我们做得更好是因为:

1. 查找需要每个条目有一条匹配记录,而SQL优化器必须假设连接不是唯一的。这就是像这里这样展开星形/雪花模式的情况。

2. 查找步骤真的很智能,只读取所需的数据并将其保存在内存中,提供内部 排序哈希表

3. 当已知流已排序时,上述方法尤其有效。而当 select from oneTable order by 速度很快,尤其是当表被适当索引时,同样 select from manyJoinedTables where LotsOfConditions order by

事实上,我猜想上面的条件正是SQL优化器希望找到并依赖的条件,但由于通用性而无法找到。

因此,使用更容易维护的解决方案(大多数情况下是PDI查找),如果它真的非常慢,那么将其移动到 Input Table

笔记:

• 避免 Database Lookup

• 避免 Joins ,即:明确告诉kettle,如果你知道是这样的话,它可以依赖唯一匹配。这个 Join Rows Merge Join 是有效的步骤,但仅当对传入流进行排序时。

• 使用 Filters (减少行数)尽快。甚至,在SQL中,每个规则都有例外。

• Select values .它对速度几乎没有影响!你不认为Kettle是天真地一步一步地重写值,而不是使用一个聪明的指针系统,不是吗?。

• JavaScript

• 不要将骨料分散在许多地方 Memory Group by 步骤。这些步骤中的每一步都需要先读取所有传入流,然后才能知道它是否完成,因此这是下一步的阻碍因素。

• Sorted Group by 内存分组依据 。一个例外是当内存达到其配额时,java开始在垃圾收集器上启动垃圾收集器。在这种情况下,可以使用排序将数据存储在临时磁盘上。

• 避免中间表。相反,通过添加列来构建流,当数据准备好时,将其放入 Output Table