ICDE 2015 Study (R24-4, R27-3)

11
R24-4: The DBMS - your Big Data Sommelier (R24: Query Processing 3) R27-3: A Comparison of Adaptive Radix Trees and Hash Tables (R27: Indexing) Masafumi Oyamada ICDE’15 勉強会

Transcript of ICDE 2015 Study (R24-4, R27-3)

R24-4: The DBMS - your Big Data Sommelier

(R24: Query Processing 3)

R27-3: A Comparison of Adaptive Radix Trees

and Hash Tables

(R27: Indexing)

Masafumi Oyamada

ICDE’15 勉強会

R24-4: The DBMS - your Big Data Sommelier

Yagiz Kargin , Martin Kersten , Stefan Manegold , Holger Pirk (CWI)

(目的) “インスタント分析” を実現したい

– 課題: DBMS で巨大なデータを分析しようと思うと、データのロード・索引付けに時間がかかって、すぐに分析が開始できない

(発想) メタデータを利用し、ロードするデータを絞り込む

– 科学分野ではデータが複数の “ファイル” からなり、各ファイルが

“メタデータ” を持つ(例: 取得時刻)

– クエリの条件にはメタデータから得られる情報が指定されることが多い(例: 「昨日取得したデータの平均値を計算して」)

– まずはメタデータだけをロードしておいて、実際にロードするデータ(ファイル)は条件にマッチするものだけにしよう!

(方式) メタデータを考慮した問合せ最適化 in MonetDB

– “メタデータに対する処理” が最初におこなわれるような問合せプランの書き換えルールを MonetDB のオプティマイザに導入

MonetDB チーム

発想: メタデータをつかってデータのロードを減らす

問合せ例

– place = “Japan” のデータを取得するモノ

– 本来 T_part2.csv のロードは必要ない

• place = “US” なので (メタデータ情報)

従来の DBMS

– メタデータ/実データどちらも全てロードしてから処理する

– T_part2.csv のロードは無駄に

提案方式

– 方針: メタデータだけ事前にロード

– T_part2.csv が問合せ対象に入らないことを確認し、ロードを省くことができる

[date] 2015 05/17

[place] Japan

[date] 2014 08/20

[place] US

メタデータ

ロードが楽

実データ

ロードが大変

T_part1.csv

T_part2.csv

SELECT * FROM T WHERE place = “Japan”

R24-4: The DBMS - your Big Data Sommelier

アプローチ: オプティマイザの拡張

実データ と メタデータ をプラン内で区別するようオプティマイザを拡張

プランの最適化時には、メタデータに対する処理をできるだけ最初にやるよう、プランを書き換え

メタデータは既にロードされており、すぐに処理できる

その処理結果をつかって、ロードする実データを pruning する

R24-4: The DBMS - your Big Data Sommelier

評価

データ: 地震波形の実データ (mSEED フォーマット)

– sf27: 4384ファイル, 36GB (DB にロード後は伸張され 627 GB)

問合せ: 集計値の計算

– T_4: 特定期間の波形の平均値の計算

R24-4: The DBMS - your Big Data Sommelier

(データのロードも含めた)

問合せを完了するまでの時間

インデックスを作成して利用するもの

(インデックス作成コストが大きく

フルスキャンよりも遅い)

データをフルスキャンするもの

提案方式

選択率が極めて高い場合を除き

従来方式よりもよい性能

R27-3: A Comparison of Adaptive Radix Trees and

Hash Tables

Victor Alvarez, Stefan Richter, Xiao Chen, Jens Dittrich (Saarland University)

(概要) ART [Leis, ICDE’13] の性能測定を “ちゃんと” やる

– Adaptive Radix-Tree (ART): インメモリDB向けのインデックス

– ART は “ハッシュテーブル並みの性能でレンジクエリもサポートする夢の索引” とうたわれているが、実際のところどうなの?

(目的) [Leis, ICDE’13] で欠けていた3つの評価をやる

1. 類似するデータ構造である Judy Array との比較

2. ちゃんとチューニングしたハッシュテーブルとの比較

3. レンジクエリの性能測定

(結果) ART は銀の弾丸ではない!

– ポイントクエリではハッシュテーブルに勝てず、レンジクエリではB+ Tree に勝てない(が、どちらも二番手となる性能)

Radix Tree と ART (Adaptive Radix Tree)

Radix Tree (中間ノードを圧縮したトライ / パトリシア木)

– Good: 探索時に条件分岐が発生しない (単なる配列アクセス) ため、CPU

キャッシュミスが少ない (↔ 二分木)

– Bad: まだまだメモリ利用効率が悪く、キャッシュ効率も悪い

• データがスパースでも、最大の子供数分の容量を食う

ART (Adaptive Radix Tree) [Leis, ICDE’13]

– 最適化された 256-way の Radix Tree

– ノードの圧縮: 実際の子供の数に応じて (Adaptive) ノードのデータ構造を変えることで、ノードを圧縮する

– 探索効率化: 探索処理は SIMD を活用して高速に実行

各ノードは「子ノードへのポインタ」の配列

子ノードが少ない場合でも、最大子共数分の容量を消費

子ノードの数に応じて、ノードを異なるデータ構造で表現

子ノードが多い (Dense) Radix Tree と同様の表現

子ノードが少ない (Sparse) 圧縮表現

R27-3: A Comparison of Adaptive Radix Trees and Hash Tables

ART: 子ノードの数に応じてノードのデータ構造を変更

If (子ノード数 ≤ 16)

If (子ノード数 ≤ 48)

If (子ノード数 > 48)

(1) 子ノードを持つキーのキー値を N 個並べる (探索時は、線形探索)

(2) 続いて、キーと同じ順で、子ノードへのポインタを N 個並べる

(1)256個の配列を用意し、インデックスの示すキーが子ノードを持つなら、子ノードへのポインタのポインタを格納 (探索時は、配列アクセス)

(2) 子ノードの数だけ、子ノードへのポインタを並べる

Radix Tree と同様に、子ノードへのポインタをそのまま並べる。インデックスがキー値となる

R27-3: A Comparison of Adaptive Radix Trees and Hash Tables

評価

ポイントクエリ (1Billion のタプルに対する検索)

– 比較対象 (抜粋)

• Judy Array

• Cuckoo hashing (モダンな Open addressing アルゴリズム) をつかったハッシュテーブル実装

– 結果

• Judy Array には勝つ (ART は Judy 比 2x の性能だが 2x 容量を食う)

• ハッシュテーブルには負ける (ハッシュテーブルは ART とくらべて数倍の性能)

レンジクエリ

– 比較対象

• Judy Array

• Cuckoo hashing をつかったハッシュテーブル実装

• B+-Tree

– 結果

• Judy, ハッシュテーブルには勝つ (2x の性能)

• B+-Tree には負ける

Radix Tree の改良版で ART に類似。細かな違いは論文参照

※ ART には B+-Tree と比べると木の管理がはるかに楽、という利点も

R27-3: A Comparison of Adaptive Radix Trees and Hash Tables

ポイントクエリ (Lookup throughput)

R27-3: A Comparison of Adaptive Radix Trees and Hash Tables

レンジクエリ (Lookup throughput)

R27-3: A Comparison of Adaptive Radix Trees and Hash Tables