Abstract
現在的系統大部分生成靜態分區，對於一些不適合現有分區的查詢並不友好。本文提出AdHash。
- 初始時，採用哈希分區。快捷且可並行。
- 監視數據訪問模式並通過逐步重新分發和複製經常訪問的數據來動態地適應查詢負載。
Introduction
RDF不需要預定義模式，可以方便的表示不同來源的數據，因此被社交網絡，搜索引擎等廣泛使用。傳統的集中式RDF系統，如：RDF-3X和TripleBit不能應對這過大的數據量。但是分佈式系統在組合中間成果時，可能會產生較大成本。
分佈式系統採取精準分區和複製部分三元組，來減少分區間查詢，但是問題仍然存在。
挑戰
現在的分佈式系統有兩個問題，一，分區成本，如果啓發式簡單，則在查詢期間會有過多的通信。複雜的啓發式可能會帶來巨大的預處理成本和複製率。但是經常訪問到的數據只佔總體的一小部分，應根據查詢來進行分區。二、適應性，靜態的分區並不能適應各種各樣的查詢。
本文提出了自適應哈希的方法（AdHash）：
**Lightweight Initial Partitioning： **hash triples’subjects. low cost & do not incur replication.
Hash-based Locality Awareness: 最大化可並行處理的join的數量。
Adapting by Incremental Redistribution: 對於頻繁查詢的數據進行重分配或者複製。
AdHash Architecture
2.1 Master
首先劃分數據到每個worker上，並收集特徵。然後從用戶得到查詢請求，生成查詢計劃，收集查詢中間結果，輸出最終結果給用戶。
String Dictionary: 將RDF字符串編碼成ID。
Data Partitioner: 對subject進行分區，因爲連接subject的鏈接較多。
Statistics Manager: 維護關於圖的統計信息，在全局查詢計劃或對圖進行調整時使用。
Redistribution Controller: 以熱量圖的形式進行監測，對於一些熱點pattern採用自適應增量重分配過程。
Locality-Aware Query Planner: 利用統計信息判斷是否查詢是否能在一個分區內執行。如果不能則找出溝通和連接最少的分解方式。
Failure Recovery: 存儲了字典，統計信息，模式索引，可以用來故障恢復。
2.2 Worker
Storage Module: 首先對謂詞進行哈希，簡歷謂詞索引，可直接對謂詞進行搜索。然後對於每個謂詞的三元組堆分別對主語和賓語進行哈希，可以支持利用s,p以及o,p的搜索。
Replica Index: 用於存儲和索引複製數據作爲自適應的結果，起初不包含數據，由增量重分佈（IPD）進程動態更新。
Query Processor: 兩種模式，需要通信的分佈式模型，無需通信的並行模型。
Local Query Planner: 對於上一條的並行模型，需要本地生成查詢計劃。
2.3 System overview
在對數據進行編碼和分區後，每個worker裝載三元組並收集統計信息，並彙集到主節點。Redistribution Controller利用全局統計信息將