cache-oblivious データ構造入門 @dsirnlp#5

Cache-Oblivious データ構造入門

秋葉拓哉 (@iwiwi)

2014/01/11 @ DSIRNLP 5

アウトライン

1. B-Tree が何故使われるのか？ (復習)

2. Cache-Oblivious の考え方と意義

3. Cache-Oblivious 探索木 (vEB Layout)

4. 世の中の Cache-Oblivious 事例

Cache-Oblivious データ構造入門 (@iwiwi) 3

MySQL の索引のデータ構造は？


http://dev.mysql.com/doc/refman/5.1/ja/mysql-indexes.html

!!!


B-Tree！MySQL に限らず多くのデータベースシステムは

B-Tree を使います



なんで B-Tree？普通の二分探索木じゃだめ？


なぜ B-Tree？

があるから


とhttp://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Memory_module_DDRAM_20-03-2006.jpg http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Hdd_medalist.jpg

なぜ B-Tree

メモリは高速

でも小さい

ディスクは遅い

でも大きい


大規模なデータベースはディスクに保存されていて

メモリに読み込みながら処理をする．

B-Tree のデータ構造

普通の二分探索木 B-Tree


多分木になってる（最大の分岐数m）

なぜ B-Treeの方が良いか？

大事な前提（若干雑）

1. ディスクの読み込み時間 >> 計算時間

2. ディスクである箇所を読み込むと周辺も含めてそこそこ大きく読まれる

前提より

• ディスクを読み込む回数だけを考える– 普段の議論：「O(ほげ) 時間」

– 今回の議論：「ディスクI/O 𝑂(ほげ)回」

• 一度に読み込まれるサイズを 𝐵とおく


データの探索にかかる I/O 回数

二分探索木

• 𝑂 log 𝑛 回一回の I/O で 2 分岐

B-Tree

• 𝑂 log𝐵 𝑛 回一回の I/O で Θ(𝐵)分岐！

B-Tree のほうが log𝐵倍ぐらい早い

これは平気で 10 倍とかになるので大違い！


↑ノードのサイズをブロックサイズ 𝐵に合わせる

このように

ディスクとメモリを使うなら

そのことを意識したデータ構造を

使う必要がある！


ちなみに

メモリとキャッシュメモリ間でも

似たようなことを考えないといけない


レジスタ

L1

L2

L3

メモリ

ディスク

テープ？

より一般に，「メモリ階層」を意識しないといけない（↓こういうやつ）

Cache-Oblivious とは


Cache-Oblivious


Cache-oblivious＝キャッシュを忘れて

Cache-Oblivious

えっ！？忘れてしまうの？


Cache-Aware vs. Cache-Oblivious

Cache-Aware ＝普通

ブロックのサイズ 𝐵を事前に

知っていて，それを使ってデータ構造を設計する（例：B-Tree）

Cache-Oblivious＝縛りプレイ

ブロックのサイズ 𝐵を知らないことにする！

知らないなりに頑張る

𝐵がどんな値であったとしてもいい感じになるよう頑張る

※本当はメモリサイズ𝑀というパラメータもあって，同様にそれも知らないことにする．今回は出てこないので省略


Cache-Aware vs. Cache-Oblivious

計算機の動きの前提は同じ

• 読み込みの回数を計算量とする

• 一回に 𝐵バイト読み込まれる

やりたいことも同じ（例：探索木）

ただし，Cache-Oblivious データ構造は

𝑩の値を使ってはいけない（つまり𝐵の値を事前に知らない）


Cache-Obliviousでない例

B-Treeは Cache-Oblivious ではない

ブロックサイズ 𝐵を知らないと

何分木にしていいかわからない！ブロックサイズ 𝐵を使ってデータ構造を設計している


↑ノードのサイズをブロックに合わせる

なんでそんなことをするのか？

Cache-Obliviousデータ構造の利点

１つめ：

ブロックサイズに合わせたパラメータ調整を環境ごとに行う必要がない！

ポータブル，手軽に使える




２つめ：

全てのメモリ階層ギャップに最適化される

• ディスク⇔メモリ・・・ 𝐵Mem

• メモリ⇔キャッシュ・・・𝐵Cacheどんな 𝐵の値でも性能が出る

→ どこのギャップに関しても良い性能！




２つめ：

全てのメモリ階層ギャップに最適化される

データの大きさによってボトルネックは変わる

• メモリに収まる？→ 𝐵Cache• 収まらない？→ 𝐵Mem

扱うデータのサイズによらず高性能なプログラムにできる


そんな都合の良いものが作れるの？

作れるんです！


Cache-Oblivious 探索木

(vEB Layout)


二分探索木があります


以降，三角形を二分探索木と思って下さい


でかい二分探索木をイメージして下さい


𝑛ノード

このツリーをディスクによさげに保存する


𝑛ノード

高さ

ℎ = log2 𝑛

ディスク

高さがだいたい半分のところで切る


高さ ℎ/2

上半分は約 𝒏ノードの木になる


約 𝒏ノード

高さ ℎ/2

切れ目（＝上半分の木の葉）には約 𝒏ノード


約 𝑛ノード

約 𝒏

下半分にぶら下がってる木も約 𝒏ノード


約 𝑛ノード

約 𝑛ノード

高さ ℎ/2

それが約 𝒏個ある


……

約 𝑛ノード

約 𝑛ノード

約 𝒏個

……

約 𝒏ノード×約 𝒏個


……

𝑇0

𝑇1 𝑇 𝑛𝑇2

それぞれの木を連続部分に保存！


……

𝑇0


ディスク 𝑇0 𝑇1 𝑇2 𝑇 𝑛…

それぞれの木はどうやって保存？


ディスク

約 𝒏ノード

それぞれの木はどうやって保存？


ディスク

約 𝒏ノード

再帰的に同じことをする！またこのツリーを上下に分割

こうやってツリーを保存することを


……

𝑇0


ディスク 𝑇0 𝑇1 𝑇2 𝑇 𝑛…

vEB Layout(vEB = Van Emde Boas)

と呼びます

vEB Layout の性質

Cache-Oblivious である！再帰してるだけ．ブロックサイズ 𝐵は出てこなかった．

𝐵を全く知らずに構築したのに……なんと

要素の探索が I/O 𝑂 log𝐵 𝑛 回でできる！

↑

𝑩を知ってて作った B-Treeと性能が一致！（オーダー記号に隠れた定数倍を除いて）

（𝐵：ブロックのサイズです← 忘れた人むけ）


vEB Layout の性質

Cache-Oblivious である！再帰してるだけ．ブロックサイズ 𝐵は出てこなかった．

𝐵を全く知らずに構築したのに……なんと

要素の探索が I/O 𝑂 log𝐵 𝑛 回でできる！

↑

𝑩を知ってて作った B-Treeと性能が一致！（オーダー記号に隠れた定数倍を除いて）

（𝐵：ブロックのサイズです← 忘れた人むけ）


最悪の場合でも I/O回数は2 + 4 log𝐵 𝑛回

計算量

𝑶 𝐥𝐨𝐠𝑩 𝒏 回の読み込みでできる理由

ツリーのサイズ：𝑛, 𝑛, 4 𝑛, 8 𝑛, 16 𝑛,……

いつかサイズは 𝐵以下になる

そしてその時，少なくとも 𝐵

サイズが 𝐵以下になったら一気に読み込まれる

→ 結局多分木みたいに動作する（ Ω 𝐵 分木）


ちなみに：Cache-Oblivious 関係ない話

木でこういう分割をするのは，

vEB Tree というデータ構造でも使う

vEB Tree はキーの値の範囲の条件下で

• 検索が 𝑶 𝐥𝐨𝐠 𝐥𝐨𝐠𝒏 時間

でできるおもしろデータ構造です

http://en.wikipedia.org/wiki/Van_Emde_Boas_tree


http://en.wikipedia.org/wiki/Van_Emde_Boas_tree

世の中の Cache-Oblivious事例


他の Cache-Obliviousデータ構造・アルゴリズム

データ構造• 動的な探索木 (CO B-Tree)

– さっきのは静的な木だったので実際に動的にしようと思うともっと複雑なものが必要

• 順位キュー• リスト• ……

アルゴリズム• ソート (Funnel Sort)• FFT，行列乗算• グラフ探索• ……


いっぱいあります！

Cache-Oblivious は本当に実用的か？

利点もあるけど，浸透しにくい

問題点1:

複雑すぎる物が多い理論屋さんがオーダー記法での計算量だけを考えて作っている実装したくないものが多い

問題点2:

Cache-Aware に中々勝てない定数倍の差はあり実測では速度で負けてしまう


事例

TokuDBMySQL, MariaDB用ストレージエンジン

Fractal Tree™ Index なるものを使うらしい


Fractal Tree™ Index

Wikipedia

公式


事例

確かにフラクタルっぽい（？）(※実際には Fractal Tree Index は vEB Layout より複雑なことをしています)


……

𝑇0


論文 (MIT CSAIL)

Cache-Oblivious Streaming B-treesMichael A. Bender, Martin Farach-Colton, Jeremy T. Fineman, Yonatan Fogel, Bradley Kuszmaul, and Jelani NelsonSPAA’07

Cache-Oblivious String B-TreesMichael A. Bender, Martin Farach-Colton, and Bradley C. KuszmaulPODS’06

Concurrent Cache-Oblivious B-TreesMichael A. Bender, Jeremy T. Fineman, Seth Gilbert, and Bradley C. KuszmaulSPAA’05


論文 (MIT CSAIL)

Cache-Oblivious Streaming B-treesMichael A. Bender, Martin Farach-Colton, Jeremy T. Fineman, Yonatan Fogel, Bradley Kuszmaul, and Jelani NelsonSPAA’07

Cache-Oblivious String B-TreesMichael A. Bender, Martin Farach-Colton, and Bradley C. KuszmaulPODS’06

Concurrent Cache-Oblivious B-TreesMichael A. Bender, Jeremy T. Fineman, Seth Gilbert, and Bradley C. KuszmaulSPAA’05

MIT の Cache-Oblivious 研究ガチ勢の起業！


Chief Scientist CTO Chief Architect

使っているっぽい雰囲気？


http://www.tokutek.com/wp-content/uploads/2011/11/how-fractal-trees-work.pdf

TokuDBの公式サイトにあるスライド

まとめ

• メモリ階層を意識したデータ構造

• Cache-Oblivious の考え方

• 基礎的テク：ツリーの vEB Layout

• 世の中の事例と課題

ありがとうございましたm(__)m


おまけ：van Emde Boas の発音


Peter van Emde Boasと友人である Erik D. Demaine (MIT)による発音が YouTubeで聞けます

https://www.youtube.com/watch?v=AjFtTQevtq0#t=14m15

https://www.youtube.com/watch?v=AjFtTQevtq0#t=14m15

謝辞

@kumagiさんのご意見をもとに発表時からスライドを改訂しています，ありがとうございます．

@tmaeharaさんに “van Emde Boas” さんの発音情報を教えてもらいました，ありがとうございます．


cache-oblivious データ構造入門 @dsirnlp#5

Technology