我有一個選擇左連接每個用於運行確定。 現在它永遠運行,當我刪除「每個」,它運行正常。選擇與連接永遠運行,當刪除「每個」時,它工作正常。
任何想法爲什麼?我們是否應該刪除所有「EACH」條款?也爲組和其他聯接? 這很重要,因爲這是嵌入我們的代碼在許多地方,突然事情運行速度非常緩慢。
非常感謝。
我有一個選擇左連接每個用於運行確定。 現在它永遠運行,當我刪除「每個」,它運行正常。選擇與連接永遠運行,當刪除「每個」時,它工作正常。
任何想法爲什麼?我們是否應該刪除所有「EACH」條款?也爲組和其他聯接? 這很重要,因爲這是嵌入我們的代碼在許多地方,突然事情運行速度非常緩慢。
非常感謝。
我不認爲我會建議明確指定each
或all
。這是一個不成熟的優化。 BigQuery是或者應該足夠聰明,以確定加入的最佳策略是什麼。這可能就是爲什麼你看到了加速:讓BigQuery完成繁重的工作,它計算出了一個更快的方法。
當您加入的桌子太大而無法加入時,應使用JOIN EACH。
首先,讓我解釋一下正常JOIN是如何完成的。這是如何工作的,即如果您的表格小於8兆字節,它將完全發送到運行部分查詢的每個分片。這很快,這是有效的,並不需要您的優化。如果您的表超過8 MB,則JOIN不起作用,因爲它無法向每個分片發送超過8 MB的數據。現在,對於「JOIN EACH」:無論您的表格是否大於或小於8 MB,如果您使用JOIN EACH,系統會散列您加入的任何內容,並僅將相關結果發送給每個分片,最大限度地減少運行的連接數量,並確保每個分片都具有所有相關數據。如果你對低熵參數進行加入(一切都是相似的,所以散列結果可能都以相同的碎片結束),所以你的碎片有可能沒有被最優地使用(1個碎片可能會查詢90%的碎片你的數據,讓其他X分片處理它的10%)。如果你有低於8MB的表,低熵,那麼額外的散列+這可能導致的低效率分片將解釋發生了什麼。
基本上,正如Giovanni指出的..... BQ知道該怎麼做,所以讓它做它的事情:)