代码之家 › 专栏 › 技术社区 › Hikari

SQL Server join或Pentaho Spoon查找?

star-schema pentaho-spoon data-warehouse lookup etl

1

Hikari · 技术社区 · 7 年前

什么提供了更高的性能?

使用Pentaho Spoon的表插入,然后使用数据库查找一次“连接”每个表,然后将结果插入另一个表

2 回复 | 直到 7 年前

1

Dirk Trilsbeek 7 年前

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

2

0

AlainD 7 年前

我们做得更好是因为:

查找需要每个条目有一条匹配记录,而SQL优化器必须假设连接不是唯一的。这就是像这里这样展开星形/雪花模式的情况。
查找步骤真的很智能,只读取所需的数据并将其保存在内存中,提供内部 排序哈希表
当已知流已排序时,上述方法尤其有效。而当 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