本文由學者Thomas Neumann和Gerhard Weikum於2009/09/01在《The VLDB Journal 》聯合發表
本文完整的系統RDF-3X，從最初爲RDF數據的管理和查詢而設計，具有精簡索引和查詢處理的RISC風格的結構。查詢優化器爲複雜查詢選擇最佳連接順序，成本模型=整個連接路徑的統計。RDF-3X優化了查詢，還通過分段體系結構支持在線更新：推遲對主數據庫索引的直接更新，將其應用於緊湊差異索引，以分批方式再將差異索引合併到主索引。
將三元組與相同屬性名稱映射到屬性表中，映射到列存儲，並創建頻繁連接的實例化圖。管理大規模RDF數據=存儲佈局+索引編制+查詢處理：
-
缺少全局模式和謂詞名稱的多樣性在數據庫設計存在問題。
-
通過對RDF數據細粒度建模，具有大量聯接的查詢會構成部分工作負載。這要求特定選擇查詢處理算法並謹慎優化複雜的聯接查詢；
-
聯接順序和其他執行計劃的優化需數據統計選擇性估計。
-
RDF使用XML語法且SPARQL涉及類似於XML路徑表達式的搜索模式。
RDF-3X實現基於三個關鍵原則：
-
物理設計在“大型三元組表”上創建的索引與工作負載無關，所有索引的總存儲空間小於主數據。
-
查詢處理器是RISC風格，主要依靠合併連接排序索引列表，可通過三元組表的“窮舉式”索引實現。
-
查詢優化器集中在生成執行計劃時的連接順序，採用動態規劃計劃枚舉，並使用基於RDF特定統計概要的成本模型。
大多數RDF數據庫不是隻讀的都是查詢密集型的，但必須至少支持增量加載，甚至支持在線更新新三元組，用於註釋現有數據。開發了一種暫緩索引更新的暫存體系結構處理RDF-3X用於快速查詢的主動索引。更新是在工作空間和差異索引中收集，然後以批處理合併到主數據庫索引。SPARQL查詢對構成RDF數據圖三元組的模式匹配查詢，SPARQL引入兩個查詢修飾符：distinct關鍵字指定必須消除重複項，reduce關鍵字指定可以重複但無需消除。減少關鍵字的目標是通過允許優化幫助RDF查詢，但查詢輸出存在不確定性。將RDF三元組映射到關係表上的三種方法：
- 所有三元組都存儲在單個、大型的三元組表。
- 三元組按其謂詞名稱分組，所有三元組均具有相同的謂詞名稱。
- 三元組是基於謂詞名稱聚類，基於工作負載中相同實體類或共現的謂詞。
通過創建“正確的”索引集可快速地處理合並聯接，將所有三元組存儲在壓縮聚類B+樹。三元組在B+樹中按字典排序，將SPARQL模式轉換爲範圍掃描。爲了確保僅通過執行一次索引掃描就可在模式三元組的任何位置使用變量回答所有可能的模式，在六個單獨的索引中保留S，P和O的所有六種可能排列。壓縮方案受文本檢索系統中反向列表方法的啓發，概括爲id三元組。對於壓縮，在節省空間和CPU消耗之間需權衡解壓縮或解釋壓縮項目，詳細信息如下：
算法會計算到前一個元組的增量，如果增量小，則直接編碼在頭字節；否則，爲每個樹值計算δi值並調用編碼。編碼將規模寫入標頭字節，然後寫入δi的非零尾部。在解壓縮期間，簡單從頭字節中重建大小。壓縮方案使用LZ77壓縮比原始數據壓縮更好。LZ77壓縮將索引大小縮小了兩倍，但增加了CPU時間，所以RDF-3X查詢不使用LZ77。壓縮索引主要是單獨壓縮每個葉頁。分頁壓縮優點：
-
通過B+樹遍歷查找任何頁並直接讀取三元組， 如果壓縮的塊更大，就必須解壓前頁。
-
壓縮索引就像一般B+樹，簡化了壓縮索引到引擎部分的集成並保留RISC特性。
對SPARQL，索引部分三元組而不是全部三元組，如下所示：
構建聚合索引，每個索引僅存儲三元組中的兩個條目及聚合計數（在完整三元組中該對的出現次數）。聚合索引存儲（value1，value2，count）而不是（value1，value2，value3），僞代碼如圖所示：
編譯SPARQL查詢的第一步是轉換，如圖說明了SPARQL查詢的轉化：SPARQL允許許多語法快捷方式簡化查詢公式（圖a），每個聯合查詢解析並擴展爲三元組（圖b）。三元組的每個組成部分是文字或變量。當查詢由單個三元模式組成時，可通過一次範圍掃描回答查詢。當查詢由多個三重模式組成時，將各模式的結果結合（圖d），所以需要在查詢圖（圖c）使用連接排序算法。
每個三元模式都對應於查詢圖中的一個節點，概念上每個節點對整個數據庫掃描。查詢圖中的邊反映了聯合變量的出現：當且僅當兩個節點中具有共同查詢變量時，兩個節點發生連接。使用查詢圖構造（未優化的）執行計劃如下：
- 爲每個三重圖案創建索引掃描，模式中的文字決定掃描範圍。
- 爲查詢圖中的每個邊添加連接，如果無法連接，則添加選擇。
- 如果查詢圖斷開連接，根據需要增加交叉聯繫從而獲得單個連接樹。
- 添加包含所有FILTER謂詞的選擇。
- 查詢的projection子句包含distinct選項，則添加聚合運算符消除結果重複項。
- 添加字典查找運算符，通過其轉換產生ID並返回字符串。
優化器爲目標查詢找到了最佳掃描策略和最佳連接順序。
處理析取查詢
SPARQL允許某些形式的析取：UNION表達式返回由兩個或更多模式組產生的綁定的並集。如果有任何結果，則OPTIONAL表達式將返回模式組的綁定，否則返回NULL值。在查詢轉換和優化過程中，將UNION和OPTIONAL中的模式組視爲嵌套子查詢，即首先轉換和優化嵌套模式組。在外部查詢的翻譯和優化過程中將其視爲具有特殊成本和基數的基本關係。對於UNION，我們添加模式組結果的並集，對於OPTIONAL，將結果添加到基本原則，可更積極地優化查詢。
保留結果基數
標準的SPARQL語義要求生成正確數量的變量綁定，雖然有很多重複。從處理角度，應避免產生和保留重複的額外工作。通過在查詢處理期間跟蹤每個元組的多重性來解決問題的查詢處理。掃描未聚合的索引會產生多重性，而聚合索引會報告重複數量爲多重性。聯接運算符使乘數相乘獲得每個輸出元組的重複數。
實施問題
運行時系統具有很強的RISC：大多數運算符僅處理整數編碼的ID，消耗和產生id元組流，比較ID等。三元組中的每個條目都是必須產生的id屬性，或是綁定到文字的字符串，如果在前綴中，則會影響開始/停止條件；如果未綁定的條目在前，則說明選擇。無需在運行時檢查不同條件，可在查詢編譯時處理。每個條目都是id屬性或文字。一個三元組有三個條目，則有八種組合。使用具有索引掃描運算符的八種不同實現方法的單接口， 減少系統代碼中條件分支的數量。
查詢優化的要求
優化SPARQL執行計劃的關鍵是聯接排序，其解決方案通常基於各種形式的動態規劃或隨機化。本文的執行計劃具有特定的形式：儘可能長時間使用保持順序的合併聯接，僅對最後幾個運算符使用到哈希聯接。
基於DP的計劃枚舉
尋找最佳執行計劃基於自下而上的DP框架。通過查詢圖的子圖組織DP表，維持每個子圖的最優計劃和結果輸出順序。如果有子圖有多個計劃，而又沒有計劃在另一個計劃中占主導地位，則所有計劃保留在DP表中。優化程序通過掃描基本關係爲DP表播種，播種分兩步過程：
- 優化器分析查詢，檢查在查詢的其他部分中使用了哪些變量綁定。如果未使用變量，則可使用聚合索引將其映射。
- 優化器決定要使用哪個索引。
修剪執行計劃的搜索空間基於估計的執行成本。優化器爲每個生成計劃調用成本模型，並修剪由較便宜的替代方案主導的等效計劃。優化器可在所有三重排列上使用索引，所以按任意順序生成元組，排序不僅由索引掃描創建，由選擇引起的函數依賴關係創建。
未完待續，接下篇。。。