SIGMOD’12勉強会 -Session 7-

Session 7: Storage Systems, Query

Processing and Optimization

担当：山室健（NTT）

1

【SIGMOD2012勉強会】

Today Outline

1. bLSM: A General Purpose Log Structured Merge Tree

Russell Sears, Yahoo! Research; Raghu Ramakrishnan, Yahoo! Research

2. NoDB: Efficient Query Execution on Raw Data File

Ioannis Alagiannis, EPFL; Renata Borovica, EPFL; Miguel Branco, EPFL; Stratos Idreos, CWI; Anastasia Ailamaki, EPFL

3. Skeleton Automata for FPGAs: Reconfiguring without Reconstructing

Jens Teubner, ETH Zürich; Louis Woods, ETH Zürich; Chongling Nie, ETH Zürich

2 Session 7: Storage Systems, Query Processing and Optimization 担当：山室健（NTT）



- Russell Sears, Yahoo! Research; Raghu Ramakrishnan, Yahoo! Research


論文概要

Update/insert-intensiveな環境向けのLSM木（’96年）の改良であるbLSM木*1を提案、 B木に近いlookup/scan性能と時間有界保証のあるmerge処理（後述）を実現

技術背景

B木の特徴

scan/lookup性能はほぼ最適

update/insertの際のシーク回数はやや多い

LSM木の特徴

ならし解析的にupdate/insertのコストが良い

scan/lookupの際のシーク回数が要素数の対数必要

update/insertが内部データのmerge処理に阻害される


*1Yahoo!のPNUTS[10]/Walnut[9]のバックエンドとして使用

update -- read&modify values

insert – append a new key/value pair

lookup – read a single key/value pair

scan – read a range of key/value pairs


論文概要

Update/insert-intensiveな環境向けのLSM木（’96年）の改良であるbLSM木*1を提案、 B木に近いlookup/scan性能と時間有界保証のあるmerge処理（後述）を実現

技術背景

B木の特徴

scan/lookup性能はほぼ最適

update/insertの際のシーク回数はやや多い

LSM木の特徴

ならし解析的にupdate/insertのコストが良い

scan/lookupの際のシーク回数が要素数の対数必要

update/insertが内部データのmerge処理に阻害される


*1Yahoo!のPNUTS[10]/Walnut[9]のバックエンドとして使用

update -- read&modify values

insert – append a new key/value pair

lookup – read a single key/value pair

scan – read a range of key/value pairs

bLSM木

目標

改善

継承


LSM木[25]の概要

update/insert-intensiveな環境に最適化された索引木


参考文献[25]のFigure2.2から引用

（Merge処理の概要）

変更内容をメモリ上（図のC0）で遅延させてバッチ的にディスク上のデータ（図でC1

*1）にmerge

merge処理は順読み込みのみ

シーク回数を最小化

検索は遅い

分割されている全てのデータ（図のC0とC1 ）が検索対象となるため

merge処理がupdate/insertを阻害

*1ディスク上のデータは段階的に複数個で構成されていても良い、つまりC1、C2、C3・・・


LSM木の様々な適用例

Google Bigtable

Apache HBase

Cassandra pre1.0

sizeに応じた2段階粒度のmerge処理： major&minor compaction

TokuDB

LevelDB

exponential-sized level、file partitioning、fractional cascading

Riak

LevelDB + customized merge scheduler & bloom filter



LSM木の課題: merge処理がupdate/insertを阻害

merge処理中のinsertのlatencyが増大（下図）


引用: MySQL vs. LevelDB, https://github.com/m1ch1/mapkeeper/wiki/MySQL-vs.-LevelDB


bLSMの概要

lookup/scan処理の最適化

C0、C1とC2の3-level固定の構成/bloom filter/file partitioning

Merge処理の最適化

Level Schedulerによるupdate/insertとmerge処理の同期化


本論文内のFigure 1から引用


Level(Spring & Gear) Scheduler

update/insertで書き込むデータとmerge量との比率（ギア比）を調整して、それぞれのスレッドを同期化

APが行うupdate/insertを中断させず継続させることが目的


各スレッドをスケジューラで同期化

※絵で描くのは簡単だが、実装は大変らしいです→https://github.com/sears/bLSM

本論文内のFigure 1/5から引用


bLSMの性能概要 Update系の処理はLevelDB（LSM木）に対しても有利

R/Wの際のRの処理をBloom-Filterで最適化

Lookup/scan系の処理もB+Treeに近い性能 Bloom FilterとPartitioning

UniformなUpdateは有界時間で完了ただし、集中したUpdateの場合は保証できない


シーク回数

本論文内のTable 1から引用







シーク回数



bLSMの性能結果

Schedulerの恩恵により、latencyのスパイクが減少



左がbLSM木、右がLSM木（LSM木）


bLSMの性能結果

lookup性能がB木（InnoDB）より良い結果に

未記載だがshort-range scanはInnoDBの性能が良い




bLSMの性能結果

lookup性能がB木（InnoDB）より良い結果に

未記載だがshort-range scanはInnoDBの性能が良い



bLSM木は100% writeで

33,000ops/sec.



- Ioannis Alagiannis, EPFL; Renata Borovica, EPFL; Miguel Branco, EPFL;

Stratos Idreos, CWI; Anastasia Ailamaki, EPFL


論文概要

データ規模が大きくなるにつれてコストが高くなるDBへのデータロードの課題に着手、データのロードをなくしつつ既存のDB機能を利用する新たなシステムデザイン（NoDB）の提案、またこれをPostgreSQL上に実装したPostgreRawを提示

研究背景

CIDER’11の”Here are my Data Files. Here are my Queries. Where are my Results?”[15]のAdaptive Loadingが先駆け

ICDE’12でAilamaki先生が「The Future of Scientific Data Bases」パネリストとして参加、NoDBの話題

SIGMOD’12採択←いまここ



NoDBの目標

必要なデータをRawFile（CSVファイル等）から適宜読み込み解析する（In situ Processing）ことで、ロード時間をなくしロード済みのDBとほぼ同等の性能を目指す



※Q1～Q4は任意のクエリを表している

DBMS w external files?

Oracle/PostgreSQL/MySQL等にはRawFileを内部Relationとしてみせる機能が実装済み


「DBMS w external files」との差分機能

1. Selective tokenizing/parsing/tuple formation

RawFileにおける各行の必要カラムのみを変換

2. Adaptive indexing (positional map)

B木のように全ての行の対応関係を保持

するのではなく参照

に応じて適宜記憶

3. Tuple caching

一度読み込んだtupleを参照頻度に応じてcaching




性能評価

PostgresRaw PM + C (Positional Map + Cache enabled)

クエリQ1～Q9の詳細は明記無し・・・

単純なWHERE句を用いたSELECTでselectivity/projectivityを変化




3. Skeleton Automata for FPGAs

- Jens Teubner, ETH Zürich; Louis Woods, ETH Zürich; Chongling Nie, ETH Zürich


論文概要

部分的な処理をオフロードする処理の記述能力を落とさずにFPGAにおけるコンパイルコストを解消したXML Projection（ストリームデータのFiltering処理）を実現


引用: wikipediaのFPGA項

※FPGAはプログラム可能なLSIのこと

技術背景

処理の高速化を目的に部分的処理をFPGAにオフロード

処理に応じたプログラムの組み替え（コンパイル）に数時間かかることも


余談


引用: http://japan.zdnet.com/development/analysis/35021200/


XML Projection[14]

クエリに記述された条件に合致する要素を抽出(Filtering）


XML Projection処理例:


右図の赤背景部を抽出


基本アプローチ XML ProjectionはNFAに変換可能

[N|D]FAはFPGA上で容易に表現可能

Skeleton Automata： FAの雛型をもちいることでパラメータの変更のみで処理の変更に対応


本論文内のFigure 3/4から引用

NFAのイプシロン遷移に対応


性能評価 Saxon-EEを用いたFiltering（下図網掛け棒）との比較

in-memory処理向けのXMLプロセッサ

XMark benchmark suite [22].を使用



SIGMOD’12勉強会 -Session 7-

Documents

Transcript of SIGMOD’12勉強会 -Session 7-