SQL Server加入或Pentaho勺查找？

Question

什麼提供更高的性能？

1. 編寫使用T-SQL，連接表，然後將結果插入到另一個表

2. 使用Pentaho的勺子的表插入，然後利用數據庫查找在同一時間以「加盟」每個表的查詢，然後將結果到另一個表

的目標是採取非規範化表，通過他們的文字與5個維表加入吧，和檢索尺寸的PK，然後將結果插入到一個事實表。

Answer 1

可能更適合dba.stackexchange.com。但是我猜數據庫引擎會更快地執行這個任務，因爲a）它可以使用索引和表統計來優化對涉及的所有表的訪問，以及b）擺脫ETL工具和多個數據庫查詢引入的開銷。 Pentaho PDI單獨處理行，因此對於來自表輸入步驟的每一行，您都將爲每個查找步驟提供一個SQL查詢。

Answer 2

認爲SQL在複雜查詢上勝過Pentaho PDI是傳統的看法。真相來自盲目相信SQL優化器提供了一個真正的最優化。

我有很多計數器示例，我們通過將SQL查詢複雜度提取到一系列查找和過濾器中，將查詢時間縮短了一個多小時到幾分鐘。

我們更好，因爲：

1. 查找預計每個條目一個匹配的記錄，而SQL優化器必須假定連接是不是唯一的。這就是像這樣展開星型/雪花模式的情況。

2. 查找步驟是很聰明，讀書只是需要的數據並將其保存在內存中，從而提供具有內部排序哈希表加快即將查詢。

3. 當流量已知被排序時，上述特別有效。雖然select from oneTable order by很快，特別是當表格被適當編入索引時，同樣的select from manyJoinedTables where LotsOfConditions order by可能效率非常低，因爲SQL不能指望索引。

事實上，我猜上述條件正是SQL優化器希望找到並依賴的條件，但不能因爲一般性。

根據經驗，我們對PDI的效率很有信心。 Matt Casters和Jens Bleuel製作了一款非常好的軟件，它在音量條件下進行了測試，您甚至無法想象。

因此，使用更容易維護的解決方案（大多數時間PDI查找），如果它確實真的很慢，那麼將其移至Input Table s，但不要期望系統更好。

注：

• 避免Database Lookup（準備語句使用緩存，但我們在正是我們期待一個不同的密鑰每次的情況下）。

• 避免Joins，即：明確地告訴壺它可以指望一個獨特的匹配，如果你知道是這樣的話。 Join Rows和Merge Join是有效的步驟，但只有當傳入流被排序時。

• 儘快使用Filters（減少行數）。即使在SQL中，每條規則都有其例外。

• 不用費心去減少Select values的列數。它對速度幾乎沒有影響！你不是那種事情，水壺是天真地重寫一步一步的值，而不是使用一個聰明的指針系統，不是嗎？

• 帶有JavaScript的計算效率並不如傳說所說的那麼低，事實上PDI通常在排序和查找中更忙碌。

• 請勿在許多Memory Group by步驟中散佈聚合體。這些步驟中的每一步都需要先讀取所有傳入流，才能知道它已完成，因此這是後續步驟的阻塞因素。

• 通常Sorted Group by不會改進Memory Group by。有一個例外是內存達到配額時，java開始在垃圾收集器上啓動垃圾收集器。在這種情況下，可以使用排序來將數據存儲在臨時磁盤上。

• 避免中間表。相反，通過添加列來構建流，並且在數據準備就緒時，將它放在Output Table中，並提交大量提交。