1. 【SIGMOD2010勉強会】
Session 8: Leveraging Hardware for
Data management
担当: 山室健(NTT)
Session 8: Leveraging Hardware for Data
1
management 担当:山室健(NTT)
2. Research Session 8:
Leveraging Hardware for Data management
論文中の図参照番号
[1] FAST: Fast Architecture Sensitive Tree Search on Modern CPUs and GPUs
Changkyu Kim, Jatin Chhugani, Nadathur Satish, Eric Sedlar, Anthony D. Nguyen, Tim Kaldewey,
Victor W. Lee, Scott A. Brandt, Pradeep Dubey
[2] Fast In-Memory Sort on Modern CPUs and GPUs: A Case for Bandwidth-
Oblivious SIMD Sort
Nadathur Satish, Changkyu Kim, Jatin Chhugani, Anthony D. Nguyen, Victor W. Lee, Daehyun Kim,
Pradeep Dubey
[3] Page-Differential Logging: An Efficient and DBMS-independent Approach for
Storing Data into Flash Memory
Yi-Reun Kim, Kyu-Young Whang, Il-Yeol Song
[4] Similarity Search and Locality Sensitive Hashing using Ternary Content
Addressable Memories
Rajendra Shinde, Ashish Goel, Pankaj Gupta, Debojyoti Dutta
2 Session 8: Leveraging Hardware for Data management 担当:山室健(NTT)
3. FAST: Fast Architecture Sensitive Tree Search on Modern
CPUs and GPUs
研究概要
Tree Searchは、メモリアクセスで大きくレイテンシの影響を受ける割に、CPU内の演算処
理(主に比較処理)は相対的に少ない
メモリアクセスのレイテンシは、CPUキャッシュの約100倍程度
キャッシュヒット率を考慮したTreeの構造化と、ベクトル命令を利用した計算密度の向上
によるTree-Searchの高速化を実現
Hierarchical Blocking
3種類のBlockでTree内のノードを配置
SIMD Blocking: ベクトル命令で同時に実行する比較キーのBlock
Cache line Blocking: データキャッシュを考慮したBlock
Page Blocking: アドレスキャッシュ(TLB)を考慮したBlock
Throughputの最大化分析
単一クエリを処理する際に発生
レイテンシを分析し、それを
隠ぺいするために必要な同時
クエリ数を推定
[1]より引用
3 Session 8: Leveraging Hardware for Data management 担当:山室健(NTT)
4. FAST: Fast Architecture Sensitive Tree Search on Modern
CPUs and GPUs
評価実験
Hierarchical BlockingをCPUとGPU向けに実装し評価
データ数が大きくなるとCPU向けの実装では、メモリバンド幅が(CPU処理よりも先に)ボ
トルネックになる結果
GPUがCPUと比較し、メモリバンド幅が大きいため、データ数が多いところではGPUが有
利
今後のアルゴリズムの方向性
今後CPUコア当たりが利用可能なメモリバンド幅は減少傾向[27]
処理あたりに必要なデータ量は極力小さく設計しなければ、今後のコア数増大に伴う性
能向上の恩恵を得られない
圧縮評価
ノード内の比較キーをδ 符号を
利用して圧縮することで15-20
%の実行時間の短縮効果
[1]より引用
4 Session 8: Leveraging Hardware for Data management 担当:山室健(NTT)
5. Fast In-Memory Sort on Modern CPUs and GPUs:
A Case for Bandwidth-Oblivious SIMD Sort
研究概要
データベース操作で一般的なオンメモリSort処理の、メモリバンド幅を考慮しながらアー
キテクチャ志向の最適化を用いた高速化
比較を行わないRadix-Sortと、比較を行うMerge-Sortの2つを評価
Radix-Sort
値を桁ごとに分割し、各桁毎にソートを行う手法
各桁のソートにはヒストグラムを用いる、Counting-Sort [10]を適用
ヒストグラムの作成には、prefix-sumを利用した並列リダクションを適用
2パタンのアーキテクチャ志向の実装
Buffer-based Scheme: ヒストグラムの書き出しをバッファリングすることで軽減する手法
Local Sort-based Scheme: ベクトル命令を利用した並列リダクションの高速化 [6,22,24]
Merge-Sort
ソート済みのサブリストを連結しながら最終的に1つの
ソート済みリストを作成
ベクトル命令を利用したbitonic mergenetwork
アルゴリズム[8]を適用した並列Merge-Sortを実装
5 Session 8: Leveraging Hardware for Data management 担当:山室健(NTT) [2]より引用
6. Fast In-Memory Sort on Modern CPUs and GPUs:
A Case for Bandwidth-Oblivious SIMD Sort
評価実験
前述のRadix-SortとMerge-SortをCPUとGPU向けに実装し評価
CPUのRadix-SortはBuffer-based Schemeを、GPUはLocal Sort-based Schemeを適用(結果が最も良かったもの
を採用)
現状のCPU/GPU性能では、全てのパタンでCPUボトルネック
データサイズが大きくなった場合、各アルゴリズムの計算量の差が結果に表れている
Radix-SortはO(N)、Merge-SortはO(NlogN)
ただし、計算量当たりの必要データ量は断然Radix-Sortが大きい
今後のアルゴリズムの方向性
今後CPUコア当たりが利用可能なメモリバンド幅は減少傾向[21]にあるため、Merge-SortがRadix-
Sortと比較し有利
ベクトル命令長が増えることも予測され、その場合もMerge-Sortが有利
[2]より引用 [2]より引用
6 Session 8: Leveraging Hardware for Data management 担当:山室健(NTT)
7. Page-Differential Logging: An Efficient and DBMS-independent
Approach for Storing Data into Flash Memory
研究概要
2次記憶装置として広く使われているFlash Memory上のデータ読み書きに関して、従来手法の相反す
る問題を解決するためのデータ管理方式の研究
2種類の従来手法と、それらの問題
Page-based
データに変更が有った場合、ページ(書込みの最小単位)全体をFlash Memory上に書き込む方式
読み込みは速いが、書込みは変更されていないデータ部分まで書き込む必要有
Log-based
変更箇所の差分情報のみを書き込む方式
書込みは速いが、読み込みはベースとなるページと、差分情報を
全て読み込む必要有
Page-Differential Logging
writing difference only
差分のみを書込み
a-most-one-age writing
複数回更新が有った場合、差分情報を1つに まとめて書込み
at-most-two-page reading
読み込みはベースページと、差分情報が含まれるページの
2ページとなるように制御 [3]より引用
7 Session 8: Leveraging Hardware for Data management 担当:山室健(NTT)
8. Page-Differential Logging: An Efficient and DBMS-independent
Approach for Storing Data into Flash Memory
評価実験
提案手法(PDL)と、その他3つの従来手法のI/O timeを比較
Out-place update(OPU) scheme[9]と、In-place update(IPU) schemeの2つのPage- basedアプロー
チ
in-page logging method[13]のlog-basedアプローチ
概ね予想通りの結果
Page-baseアプローチ(OPU, and IPU)は読み込みが速く、書込みが遅い
Log-basedアプローチは、Page-baseの逆の結果
それらに対し、提案手法はそれらの中間となるような結果に
TPC-C(業務系のOLTPを想定)を使った総合的なI/O timeも、提案手法が最も速い
[3]より引用 [3]より引用
8 Session 8: Leveraging Hardware for Data management 担当:山室健(NTT)