toplogo
登入

基於投影的合取查詢列舉演算法


核心概念
本文探討了星型查詢和路徑查詢這兩種重要類型的CQs投影查詢的結果列舉問題,重點關注於設計能夠在預處理階段後,以具有延遲保證的方式高效列舉結果的資料結構和演算法。
摘要

研究背景

在靜態資料庫上高效地評估連接查詢是資料管理中的一個基本問題。 長期以來,研究人員一直致力於設計和分析能夠根據輸入和輸出大小最小化查詢執行總運行時間的演算法。 然而,在許多資料處理場景中,將查詢執行分為兩個階段是有益的:預處理階段和列舉階段。預處理階段計算一個空間高效的中間資料結構,而列舉階段則使用該資料結構盡可能快地列舉查詢結果,以最小化輸出結果中兩個連續元組之間的延遲。這種區分在以下幾個方面都是有益的:例如,在許多情況下,用戶希望盡快看到查詢的一個(或幾個)結果,在這種情況下,我們希望最小化預處理階段的時間,以便我們可以快速輸出第一個結果。另一方面,資料處理管道可能要求下游任務多次訪問查詢結果,在這種情況下,在預處理階段花費更多時間以保證更快的列舉速度和更小的延遲是更好的選擇。

研究現狀

資料庫文獻中的先前工作主要集中在尋找能夠以 O(|D|) 預處理時間(其中 D 是輸入資料庫實例)和在列舉階段具有恆定延遲來計算的查詢類別。該研究方向的主要結果表明,完全(即沒有投影)的非循環連接查詢 (CQ) 允許線性預處理時間和恆定延遲。如果 CQ 不是完全的,但其自由變數滿足自由連接屬性,則仍然可以實現相同的預處理時間和延遲保證。眾所周知,對於任何(可能是非完全的)非循環 CQ,在線性預處理時間後可以實現線性延遲。先前使用結構分解方法的工作將這些結果推廣到具有自由變數的任意 CQ,並表明可以使用 O(|D|fhw) 延遲列舉投影解,其中 fhw 是查詢的分數超樹寬度。此外,還顯示了關於具有固定數量元的連接查詢類別的二分法,其中可以使用多項式延遲 (WPD) 計算此類答案。當 CQ 是完全的但不是非循環的時,分解資料庫使用 O(|D|fhw) 預處理時間來實現恆定延遲。我們在此應當指出,我們始終可以在預處理期間計算和實例化查詢結果以實現恆定延遲列舉,但这需要指數級的空間。

研究問題

上述先前工作研究了預處理時間-延遲權衡空間中的特定點。雖然完全非循環 CQ 的情況相對完整,但對於一般 CQ 而言並非如此,即使對於具有投影的非循環 CQ 也是如此。例如,考慮最簡單的此類查詢:Qtwo-path = πx,z(R(x, y)⋊⋉S(y, z)),它連接兩個二元關係,然後投影出連接屬性。對於此查詢,[BDG07] 排除了除非布爾矩陣乘法指數為 ω = 2,否則具有線性時間預處理的恆定延遲演算法。但是,我們可以通過 O(|D|) 預處理時間獲得 O(|D|) 延遲。我們還可以通過計算和存儲完整結果,通過 O(|D|2) 預處理獲得 O(1) 延遲。值得一問的是,在預處理時間和延遲之間的這種權衡中,是否存在其他有趣的點。為此,Kara 等人的開創性工作表明,對於任何分層 CQ1(可能帶有投影),預處理時間和延遲之間始終存在平滑的權衡。這是十多年來對涉及投影的查詢的 Bagan 等人結果的首次改進。應用於查詢 Qtwo-path,[KNOZ20] 的主要結果表明,對於任何 ϵ ∈[0, 1],我們可以通過 O(|D|1+ϵ) 預處理時間獲得 O(|D|1−ϵ) 延遲。

本文貢獻

在本文中,我們繼續研究具有投影的 CQ 的預處理時間和延遲之間的權衡。我們專注於兩類 CQ:星型查詢和路徑查詢。星型查詢是分層查詢的一個流行子集,而路徑查詢是非分層查詢中的一個有用子集。我們出於兩個原因而專注於這兩類。首先,星型查詢在實踐中具有極大的意義,因為它們與集合交集、集合相似性連接以及實體匹配的應用有關。實踐中最常見的星型查詢是 Qtwo-path。路徑查詢也是如此,它們在圖形處理中至關重要。其次,正如我們將在本文中看到的那樣,權衡情況很複雜,即使對於簡單的星型查詢類別也需要開發新技術。我們還提供了一個關於稱為左深度的分層 CQ 子集的結果。我們的關鍵見解是設計列舉演算法,這些演算法不僅依賴於輸入大小 |D|,而且還了解其他特定於資料的參數,例如輸出大小。

主要結果

為了說明我們的結果,以 Qtwo-path 為例,並用 OUT⋊
⋉表示底層完整查詢的輸出(即 R(x, y)⋊⋉S(y, z))。我們可以顯示以下結果:

定理 1.1 給定任何資料庫實例 D,在 O(|D|) 預處理時間之後,可以使用 O(|D|2/|OUT⋊
⋉|) 延遲列舉 Qtwo-path = πx,z(R(x, y)⋊⋉S(y, z)) 的輸出。

在這個時候,讀者可能會想知道上述結果的改進之處。[KNOZ20] 意味著在預處理時間為 O(|D|) 的情況下,最壞情況下的延遲保證為 O(|D|)。這就引出了一個問題,即定理 1.1 中的延遲是否是真正的演算法改進,而不僅僅是對 [KNOZ20] 的改進分析。我們肯定地回答了這個問題。具體來說,我們表明存在一個資料庫實例,其中從定理 1.1 獲得的延遲是對 [KNOZ20] 的實際保證的多項式改進,而不僅僅是最壞情況。我們提出的演算法通過巧妙地使用存儲的預先計算輸出來保持延遲保證,並與生成新輸出但速度不足以滿足延遲保證的進一步連接處理交替進行,從而優於先前的工作。當預處理時間為線性時,我們結果所暗示的延遲取決於完整連接的大小。對於 |OUT⋊
⋉| = Θ(|D|2) 的最壞情況輸出大小,我們獲得了最佳延遲,這將是恆定的。將此與 [KNOZ20] 的結果進行比較,後者需要接近 O(|D|2) 的預處理時間才能實現相同的保證。另一方面,如果 |OUT⋊
⋉| = Θ(|D|),我們只獲得 O(|D|) 的線性延遲保證。讀者可能會想知道我們的結果通常與 [KNOZ20] 中最壞情況下的權衡相比如何;我們將證明,我們始終可以獲得至少與 [KNOZ20] 中一樣好的權衡點。圖 1 總結了先前的工作和本文中提出的結果。

主要貢獻

在本文中,我們改進了具有投影的 CQ 子集的最先進的預處理時間-延遲權衡。我們在下面總結了我們的主要技術貢獻(圖 1 中突出顯示):

(1) 我們的第一個貢獻是一種新穎的演算法(定理 4.1),該演算法在線性預處理時間後實現了星型查詢(在第 2.3 節中正式定義)的輸出相關延遲保證。具體來說,我們可以在線性預處理後實現 O(|D|k/(k−1)/|OUT⋊
⋉|1/k−1) 延遲。我們的關鍵思想是確定一個適當的度數閾值,將關係劃分為重分區和輕分區,這使我們能夠執行高效的列舉。對於星型查詢,我們的結果意味著預處理時間和延遲保證之間沒有 [KNOZ20] 中所述的針對一般分層查詢類別的平滑權衡。

(2) 我們在列舉演算法的背景下引入了交錯連接查詢計算的新穎思想,這構成了我們演算法的基礎,並且可能具有獨立的意義。具體來說,我們表明可以將兩個演算法 A 和 A' 的輸出與 δ 延遲保證進行合併,其中 A 以 δ 延遲保證列舉查詢結果,而 A' 則沒有。當無法以良好的延遲保證進行列舉時,此技術允許我們動態計算查詢的子集。

(3) 我們使用快速矩陣乘法技術來獲得比 [KNOZ20] 更好的預處理時間-延遲權衡。我們還展示了一種用於具有線性預處理時間和輸出相關延遲保證的左深度分層查詢的演算法。

(4) 最後,我們提出了關於非分層 CQ(路徑查詢類別)(在第 2.3 節中正式定義)的預處理時間-延遲權衡的新結果。我們的結果表明,對於任何 ϵ ∈[0, 1),我們可以通過 O(|D|2−ϵ/(k−1)) 預處理時間實現延遲 O(|D|ϵ)。

edit_icon

客製化摘要

edit_icon

使用 AI 重寫

edit_icon

產生引用格式

translate_icon

翻譯原文

visual_icon

產生心智圖

visit_icon

前往原文

統計資料
當 |OUT⋊⋉| = Θ(|D|k) 時,演算法可以在線性時間預處理後實現恆定延遲。 當 |OUT⋊⋉| = Θ(|D|) 時,演算法可以實現線性延遲。 當 |OUT⋊⋉| 具有線性大小時,我們可以在線性預處理時間內計算和實例化查詢結果,並實現恆定延遲列舉。
引述

從以下內容提煉的關鍵洞見

by Shaleen Deep... arxiv.org 11-21-2024

https://arxiv.org/pdf/2101.03712.pdf
Enumeration Algorithms for Conjunctive Queries with Projection

深入探究

如何將本文提出的演算法推廣到更廣泛的查詢類別,例如包含選擇操作的查詢?

將本文提出的枚舉演算法推廣到包含選擇操作的查詢,需要克服幾個挑戰: 選擇操作的處理: 本文的演算法主要針對星型查詢和路徑查詢進行了優化,這些查詢不包含選擇操作。要處理選擇操作,需要修改預處理階段和枚舉階段的設計。一種可能的解決方案是在預處理階段根據選擇條件過濾數據,並建立相應的索引結構,以便在枚舉階段快速找到滿足條件的元組。 數據結構的調整: 本文的演算法使用了哈希表和排序列表等數據結構來存儲和訪問數據。對於包含選擇操作的查詢,可能需要使用更複雜的數據結構,例如樹狀結構或位圖索引,以便高效地執行範圍查詢或其他類型的選擇操作。 延遲保證的維持: 本文的演算法通過交錯預先計算的輸出和進一步的連接處理來維持延遲保證。對於包含選擇操作的查詢,需要仔細設計交錯策略,以確保在滿足選擇條件的同時,仍然能夠以較小的延遲枚舉查詢結果。 以下是一些可能的推廣方向: 將選擇操作下推到關係中: 對於某些選擇條件,可以將其下推到關係中,以便在預處理階段減少數據量。例如,對於查詢 πx,z(σy>10(R(x, y)) ⋈ S(y, z)),可以在預處理階段先過濾 R(x, y) 中 y 值小於等於 10 的元組。 利用索引結構: 對於包含範圍查詢或其他類型選擇條件的查詢,可以利用樹狀結構或位圖索引等數據結構來加速查詢處理。例如,可以使用 B+ 樹來索引 y 值,以便快速找到滿足 y>10 條件的元組。 調整交錯策略: 需要根據選擇條件的複雜性和數據分佈情況,調整交錯預先計算的輸出和進一步連接處理的策略,以維持較小的延遲保證。 總之,將本文提出的演算法推廣到包含選擇操作的查詢需要對演算法進行非平凡的修改。需要根據具體的查詢和數據特點,設計高效的數據結構和演算法,以克服選擇操作帶來的挑戰。

本文提出的演算法在實際應用中的性能如何?是否存在可以進一步提高演算法效率的優化方法?

本文提出的演算法在實際應用中的性能,取決於多個因素,包括數據集的大小、數據分佈、查詢的具體形式以及系統的硬件配置等。 優點: 輸出敏感性: 本文提出的演算法的一個主要優點是其輸出敏感性,即其延遲保證與查詢結果的大小相關。對於輸出結果較小的查詢,該演算法可以實現較低的延遲。 線性預處理時間: 對於星型查詢,該演算法只需要線性預處理時間,這對於大型數據集而言是一個顯著的優勢。 潜在的限制: 實際性能: 雖然理論上具有較好的延遲保證,但在實際應用中,演算法的性能可能會受到數據分佈和系統配置等因素的影響。例如,哈希表的性能在最壞情況下可能會退化到線性時間,這會影響演算法的整體效率。 空間複雜度: 演算法需要額外的空間來存儲預處理的結果和中間數據結構,這對於内存資源有限的系統可能是一個問題。 優化方法: 數據分區: 可以根據數據分佈情況對數據進行分區,並對每個分區分別應用演算法,最後合併結果。這種方法可以利用數據局部性,提高緩存命中率,從而提高演算法的效率。 並行處理: 可以利用多核處理器或分佈式計算框架,將演算法的各個階段並行化,以縮短總體運行時間。 自適應算法: 可以設計自適應算法,根據數據特點和系統負載動態調整演算法的參數,例如哈希表的大小、數據分區的數量等,以獲得更好的性能。 總之,本文提出的演算法為枚舉查詢結果提供了一種新的思路,其輸出敏感性和線性預處理時間使其在某些應用場景下具有優勢。然而,在實際應用中,需要根據具體情況對演算法進行優化,以充分發揮其性能。

如果允許近似查詢結果,是否可以設計出具有更好預處理時間和延遲保證的演算法?

如果允許近似查詢結果,則可以設計出具有更好預處理時間和延遲保證的演算法。以下是一些可能的方向: 抽樣方法: 可以使用抽樣方法從數據集中選取一部分數據進行處理,並根據抽樣結果估計 전체 查詢結果。通過調整抽樣比例,可以在預處理時間和結果精度之間進行權衡。 概要數據結構: 可以使用概要數據結構,例如 Count-Min Sketch 或 HyperLogLog,來近似計算查詢結果的大小或其他統計信息。這些數據結構通常比存儲完整數據集更节省空間,並且可以提供一定的精度保證。 近似查詢處理技術: 可以使用近似查詢處理技術,例如 Bloom filter 或 Locality Sensitive Hashing (LSH),來加速查詢處理過程。這些技術可以快速排除不滿足查詢條件的數據,從而減少需要處理的數據量。 以下是一些具體的例子: 近似星型查詢: 對於星型查詢,可以使用抽樣方法從每個關係中選取一部分元組,並僅計算這些元組的連接結果。通過調整抽樣比例,可以控制近似結果的精度和預處理時間。 近似路徑查詢: 對於路徑查詢,可以使用 LSH 技術將數據點映射到哈希桶中,並僅計算位於相同哈希桶中的數據點之間的路徑。這種方法可以有效地減少需要處理的數據量,從而提高查詢效率。 需要注意的是,近似查詢結果的精度和預處理時間之間存在權衡。需要根據具體的應用場景,選擇合适的近似方法和參數,以平衡精度和效率。
0
star