SlideShare una empresa de Scribd logo
1 de 8
Descargar para leer sin conexión
【VLDB2013 勉強会】	

R1: Emerging Hardware 	
担当: 山室健	

1
Improving Flash Write Performance by Using
Update Frequency
Radu Stoica (EPFL), and Anastasia Ailamaki (EPFL)

2	

R1: Emerging Hardware 担当:山室健
Improving Flash Write Performance by Using Update Frequency	
} 

A overview	
} 

} 

SSDの’out-of-place update’を効率的に実現するためwrite IOの
workloadによる影響のモデル化を行い、そのモデルを基にデータ配置
のpolicyを提案、結果としてDBのベンチマーク(TPC-C[24]/TATP[19])
において20-75%のGCのoverhead削減を実現	

Contribution	
} 
} 
} 

3	

予備ブロック(over-provisioning)/update頻度/データ配置policy/GC戦
略の影響のモデル化とシュミレーション	
workloadに応じたGCのoverheadの定量化	
k-modal update頻度を用いた効率的なデータ配置policyの提案、
parameter-freeで動的なworkloadに対応	

R1: Emerging Hardware 担当:山室健
Improving Flash Write Performance by Using Update Frequency	
} 

SSDにおけるupdate(pageとblock)	

引用元: http://en.wikipedia.org/w/index.php?title=Write_amplification	
4	

R1: Emerging Hardware 担当:山室健
Improving Flash Write Performance by Using Update Frequency	
} 

uni-modal〜k-modal update頻度分析	
} 
} 

	
} 

GCのoverheadは「blockをeraseする際の有効pageの割合」	
SSDの書き込み増分WA(Write Amplification)は	

※一般SSD製品のWAは1〜10程度
参考: http://www.slideshare.net/InsightTechnology/d17dbhw	
論文内Fig.2から引用: hot/cold(2-modal)に領域分割した時の
領域間の相対update頻度とGCのoverheadの関係	

分析のPractical Implications	

2つの領域(2-modal)間でupdate頻度に〜x2程度の偏りがあっても
GCのoverheadは変化しない	
 → update頻度fr推定の誤差はある程度許容	
 → fr=2, 4,..., 2kとして分割領域を決定	
} 

5	

R1: Emerging Hardware 担当:山室健
Improving Flash Write Performance by Using Update Frequency	
} 

余談)SSD上でのwrite IO操作の注意	
非効率なwriteパタンによってもWA値は悪化するケースが存在	
例)LSM木実装leveldbのcompaction処理	
・https://leveldb.googlecode.com	
} 

- O’Neil, P. et al.: The log-structured merge-tree, Acta Informatica 33, 1996	

・階層Lのnode(2MiB)から階層L+1上のoverlapするnodes(最大12nodes	
で24MiB)をmergeする処理でfan-outが多い場合にIOが4倍に悪化	
	
mergeのスケジューリングを改善したhyperleveldb	
 https://github.com/rescrv/HyperLevelDB	
	
} 

6	

R1: Emerging Hardware 担当:山室健
Improving Flash Write Performance by Using Update Frequency	
} 

データ配置policyは分析結果を基に構築	
}  1. update頻度推定は同pageへの書き込み間隔を利用したLRUベースの
MultiLogと、正確な頻度情報を仮定したMultiLog-Oracle	
}  2. 分析結果から得たGCのoverheadコスト関数(式(11))からupdateの際に
promotion判定、GCの際にdemotion判定を実施	
}  3. GCのpolicyは最後に書き込みが行われたblockを採用するLRUベース	
} 

block内の有効page数が少ないものを選択するGreedyな手法に比べて性能の劣化は少なく、
メタ情報を管理する余剰領域もいらないため実現が容易	

論文内Fig.4から引用	
7	

R1: Emerging Hardware 担当:山室健
Improving Flash Write Performance by Using Update Frequency	
} 

実験概要	
}  実験はTPC-C[24]とNokia TATP[19]のDBベンチマークを利用	
 →書き込みが多いworkloadを想定	
} 
} 
} 

page sizeは4kB/erase blockは64pagesの100GB SSDを想定	
予備ブロック割合αとGC overheadの関係を評価	
比較手法はNaiveなLRU/Greedyと、既存手法[14][26][12]の3パタン	

論文内Fig.7から引用	

8	

R1: Emerging Hardware 担当:山室健

Más contenido relacionado

Similar a VLDB2013 R1 Emerging Hardware

A12 既存のデータベース環境で分析業務を加速させるには? DB2が実現するソフトウエア分析ソリューション(DB2 BLU Acceleration)の仕...
A12 既存のデータベース環境で分析業務を加速させるには? DB2が実現するソフトウエア分析ソリューション(DB2 BLU Acceleration)の仕...A12 既存のデータベース環境で分析業務を加速させるには? DB2が実現するソフトウエア分析ソリューション(DB2 BLU Acceleration)の仕...
A12 既存のデータベース環境で分析業務を加速させるには? DB2が実現するソフトウエア分析ソリューション(DB2 BLU Acceleration)の仕...
Insight Technology, Inc.
 
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
Insight Technology, Inc.
 
Data Engineering at VOYAGE GROUP #jawsdays
Data Engineering at VOYAGE GROUP #jawsdaysData Engineering at VOYAGE GROUP #jawsdays
Data Engineering at VOYAGE GROUP #jawsdays
VOYAGE GROUP
 

Similar a VLDB2013 R1 Emerging Hardware (20)

[db tech showcase Sapporo 2015] B16:ビッグデータには、なぜ列指向が有効なのか? by 日本ヒューレット・パッカード株式...
[db tech showcase Sapporo 2015] B16:ビッグデータには、なぜ列指向が有効なのか? by 日本ヒューレット・パッカード株式...[db tech showcase Sapporo 2015] B16:ビッグデータには、なぜ列指向が有効なのか? by 日本ヒューレット・パッカード株式...
[db tech showcase Sapporo 2015] B16:ビッグデータには、なぜ列指向が有効なのか? by 日本ヒューレット・パッカード株式...
 
LBJ2016オープンステージスライド
LBJ2016オープンステージスライドLBJ2016オープンステージスライド
LBJ2016オープンステージスライド
 
A12 既存のデータベース環境で分析業務を加速させるには? DB2が実現するソフトウエア分析ソリューション(DB2 BLU Acceleration)の仕...
A12 既存のデータベース環境で分析業務を加速させるには? DB2が実現するソフトウエア分析ソリューション(DB2 BLU Acceleration)の仕...A12 既存のデータベース環境で分析業務を加速させるには? DB2が実現するソフトウエア分析ソリューション(DB2 BLU Acceleration)の仕...
A12 既存のデータベース環境で分析業務を加速させるには? DB2が実現するソフトウエア分析ソリューション(DB2 BLU Acceleration)の仕...
 
今だからこそ考えるSAP on SQL Server
今だからこそ考えるSAP on SQL Server今だからこそ考えるSAP on SQL Server
今だからこそ考えるSAP on SQL Server
 
[Cloud OnAir] 最新アップデート Google Cloud データ関連ソリューション 2020年5月14日 放送
[Cloud OnAir] 最新アップデート Google Cloud データ関連ソリューション 2020年5月14日 放送[Cloud OnAir] 最新アップデート Google Cloud データ関連ソリューション 2020年5月14日 放送
[Cloud OnAir] 最新アップデート Google Cloud データ関連ソリューション 2020年5月14日 放送
 
アドテク×Scala×パフォーマンスチューニング
アドテク×Scala×パフォーマンスチューニングアドテク×Scala×パフォーマンスチューニング
アドテク×Scala×パフォーマンスチューニング
 
リクルートを支える横断データ基盤と機械学習の適用事例
リクルートを支える横断データ基盤と機械学習の適用事例リクルートを支える横断データ基盤と機械学習の適用事例
リクルートを支える横断データ基盤と機械学習の適用事例
 
20191211_Apache_Arrow_Meetup_Tokyo
20191211_Apache_Arrow_Meetup_Tokyo20191211_Apache_Arrow_Meetup_Tokyo
20191211_Apache_Arrow_Meetup_Tokyo
 
Wandb Monthly Meetup August 2023.pdf
Wandb Monthly Meetup August 2023.pdfWandb Monthly Meetup August 2023.pdf
Wandb Monthly Meetup August 2023.pdf
 
IEEE/ACM SC2013報告
IEEE/ACM SC2013報告IEEE/ACM SC2013報告
IEEE/ACM SC2013報告
 
【de:code 2020】 Power Platform で広がるデータ インテグレーションの世界 (1/2)
【de:code 2020】 Power Platform で広がるデータ インテグレーションの世界 (1/2)【de:code 2020】 Power Platform で広がるデータ インテグレーションの世界 (1/2)
【de:code 2020】 Power Platform で広がるデータ インテグレーションの世界 (1/2)
 
[Cloud OnAir] ケーススタディから学ぶ GCP で行うデータ エンジニアリング 2019年6月6日 放送
[Cloud OnAir] ケーススタディから学ぶ  GCP で行うデータ エンジニアリング 2019年6月6日 放送[Cloud OnAir] ケーススタディから学ぶ  GCP で行うデータ エンジニアリング 2019年6月6日 放送
[Cloud OnAir] ケーススタディから学ぶ GCP で行うデータ エンジニアリング 2019年6月6日 放送
 
20180920_DBTS_PGStrom_JP
20180920_DBTS_PGStrom_JP20180920_DBTS_PGStrom_JP
20180920_DBTS_PGStrom_JP
 
組込みSW開発技術研究会キックオフミーティング
組込みSW開発技術研究会キックオフミーティング組込みSW開発技術研究会キックオフミーティング
組込みSW開発技術研究会キックオフミーティング
 
[Cloud OnAir] Talks by DevRel Vol. 1 インフラストラクチャ 2020年7月30日 放送
[Cloud OnAir] Talks by DevRel Vol. 1 インフラストラクチャ 2020年7月30日 放送[Cloud OnAir] Talks by DevRel Vol. 1 インフラストラクチャ 2020年7月30日 放送
[Cloud OnAir] Talks by DevRel Vol. 1 インフラストラクチャ 2020年7月30日 放送
 
Microsoft Azure PaaS 概要
Microsoft Azure PaaS 概要Microsoft Azure PaaS 概要
Microsoft Azure PaaS 概要
 
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
 
最適なビックデータ・システムの構築のために
最適なビックデータ・システムの構築のために最適なビックデータ・システムの構築のために
最適なビックデータ・システムの構築のために
 
Data Engineering at VOYAGE GROUP #jawsdays
Data Engineering at VOYAGE GROUP #jawsdaysData Engineering at VOYAGE GROUP #jawsdays
Data Engineering at VOYAGE GROUP #jawsdays
 
Data Engineering at VOYAGE GROUP #jawsdays
Data Engineering at VOYAGE GROUP #jawsdaysData Engineering at VOYAGE GROUP #jawsdays
Data Engineering at VOYAGE GROUP #jawsdays
 

Más de Takeshi Yamamuro

An Experimental Study of Bitmap Compression vs. Inverted List Compression
An Experimental Study of Bitmap Compression vs. Inverted List CompressionAn Experimental Study of Bitmap Compression vs. Inverted List Compression
An Experimental Study of Bitmap Compression vs. Inverted List Compression
Takeshi Yamamuro
 
浮動小数点(IEEE754)を圧縮したい@dsirnlp#4
浮動小数点(IEEE754)を圧縮したい@dsirnlp#4浮動小数点(IEEE754)を圧縮したい@dsirnlp#4
浮動小数点(IEEE754)を圧縮したい@dsirnlp#4
Takeshi Yamamuro
 
LLVMで遊ぶ(整数圧縮とか、x86向けの自動ベクトル化とか)
LLVMで遊ぶ(整数圧縮とか、x86向けの自動ベクトル化とか)LLVMで遊ぶ(整数圧縮とか、x86向けの自動ベクトル化とか)
LLVMで遊ぶ(整数圧縮とか、x86向けの自動ベクトル化とか)
Takeshi Yamamuro
 
A x86-optimized rank&select dictionary for bit sequences
A x86-optimized rank&select dictionary for bit sequencesA x86-optimized rank&select dictionary for bit sequences
A x86-optimized rank&select dictionary for bit sequences
Takeshi Yamamuro
 
研究動向から考えるx86/x64最適化手法
研究動向から考えるx86/x64最適化手法研究動向から考えるx86/x64最適化手法
研究動向から考えるx86/x64最適化手法
Takeshi Yamamuro
 
VLDB'10勉強会 -Session 2-
VLDB'10勉強会 -Session 2-VLDB'10勉強会 -Session 2-
VLDB'10勉強会 -Session 2-
Takeshi Yamamuro
 

Más de Takeshi Yamamuro (15)

LT: Spark 3.1 Feature Expectation
LT: Spark 3.1 Feature ExpectationLT: Spark 3.1 Feature Expectation
LT: Spark 3.1 Feature Expectation
 
Apache Spark + Arrow
Apache Spark + ArrowApache Spark + Arrow
Apache Spark + Arrow
 
Quick Overview of Upcoming Spark 3.0 + α
Quick Overview of Upcoming Spark 3.0 + αQuick Overview of Upcoming Spark 3.0 + α
Quick Overview of Upcoming Spark 3.0 + α
 
MLflowによる機械学習モデルのライフサイクルの管理
MLflowによる機械学習モデルのライフサイクルの管理MLflowによる機械学習モデルのライフサイクルの管理
MLflowによる機械学習モデルのライフサイクルの管理
 
Taming Distributed/Parallel Query Execution Engine of Apache Spark
Taming Distributed/Parallel Query Execution Engine of Apache SparkTaming Distributed/Parallel Query Execution Engine of Apache Spark
Taming Distributed/Parallel Query Execution Engine of Apache Spark
 
LLJVM: LLVM bitcode to JVM bytecode
LLJVM: LLVM bitcode to JVM bytecodeLLJVM: LLVM bitcode to JVM bytecode
LLJVM: LLVM bitcode to JVM bytecode
 
20180417 hivemall meetup#4
20180417 hivemall meetup#420180417 hivemall meetup#4
20180417 hivemall meetup#4
 
An Experimental Study of Bitmap Compression vs. Inverted List Compression
An Experimental Study of Bitmap Compression vs. Inverted List CompressionAn Experimental Study of Bitmap Compression vs. Inverted List Compression
An Experimental Study of Bitmap Compression vs. Inverted List Compression
 
20160908 hivemall meetup
20160908 hivemall meetup20160908 hivemall meetup
20160908 hivemall meetup
 
浮動小数点(IEEE754)を圧縮したい@dsirnlp#4
浮動小数点(IEEE754)を圧縮したい@dsirnlp#4浮動小数点(IEEE754)を圧縮したい@dsirnlp#4
浮動小数点(IEEE754)を圧縮したい@dsirnlp#4
 
LLVMで遊ぶ(整数圧縮とか、x86向けの自動ベクトル化とか)
LLVMで遊ぶ(整数圧縮とか、x86向けの自動ベクトル化とか)LLVMで遊ぶ(整数圧縮とか、x86向けの自動ベクトル化とか)
LLVMで遊ぶ(整数圧縮とか、x86向けの自動ベクトル化とか)
 
A x86-optimized rank&select dictionary for bit sequences
A x86-optimized rank&select dictionary for bit sequencesA x86-optimized rank&select dictionary for bit sequences
A x86-optimized rank&select dictionary for bit sequences
 
VAST-Tree, EDBT'12
VAST-Tree, EDBT'12VAST-Tree, EDBT'12
VAST-Tree, EDBT'12
 
研究動向から考えるx86/x64最適化手法
研究動向から考えるx86/x64最適化手法研究動向から考えるx86/x64最適化手法
研究動向から考えるx86/x64最適化手法
 
VLDB'10勉強会 -Session 2-
VLDB'10勉強会 -Session 2-VLDB'10勉強会 -Session 2-
VLDB'10勉強会 -Session 2-
 

VLDB2013 R1 Emerging Hardware

  • 1. 【VLDB2013 勉強会】 R1: Emerging Hardware 担当: 山室健 1
  • 2. Improving Flash Write Performance by Using Update Frequency Radu Stoica (EPFL), and Anastasia Ailamaki (EPFL) 2 R1: Emerging Hardware 担当:山室健
  • 3. Improving Flash Write Performance by Using Update Frequency }  A overview }  }  SSDの’out-of-place update’を効率的に実現するためwrite IOの workloadによる影響のモデル化を行い、そのモデルを基にデータ配置 のpolicyを提案、結果としてDBのベンチマーク(TPC-C[24]/TATP[19]) において20-75%のGCのoverhead削減を実現 Contribution }  }  }  3 予備ブロック(over-provisioning)/update頻度/データ配置policy/GC戦 略の影響のモデル化とシュミレーション workloadに応じたGCのoverheadの定量化 k-modal update頻度を用いた効率的なデータ配置policyの提案、 parameter-freeで動的なworkloadに対応 R1: Emerging Hardware 担当:山室健
  • 4. Improving Flash Write Performance by Using Update Frequency }  SSDにおけるupdate(pageとblock) 引用元: http://en.wikipedia.org/w/index.php?title=Write_amplification 4 R1: Emerging Hardware 担当:山室健
  • 5. Improving Flash Write Performance by Using Update Frequency }  uni-modal〜k-modal update頻度分析 }  }  }  GCのoverheadは「blockをeraseする際の有効pageの割合」 SSDの書き込み増分WA(Write Amplification)は ※一般SSD製品のWAは1〜10程度 参考: http://www.slideshare.net/InsightTechnology/d17dbhw 論文内Fig.2から引用: hot/cold(2-modal)に領域分割した時の 領域間の相対update頻度とGCのoverheadの関係 分析のPractical Implications 2つの領域(2-modal)間でupdate頻度に〜x2程度の偏りがあっても GCのoverheadは変化しない  → update頻度fr推定の誤差はある程度許容  → fr=2, 4,..., 2kとして分割領域を決定 }  5 R1: Emerging Hardware 担当:山室健
  • 6. Improving Flash Write Performance by Using Update Frequency }  余談)SSD上でのwrite IO操作の注意 非効率なwriteパタンによってもWA値は悪化するケースが存在 例)LSM木実装leveldbのcompaction処理 ・https://leveldb.googlecode.com }  - O’Neil, P. et al.: The log-structured merge-tree, Acta Informatica 33, 1996 ・階層Lのnode(2MiB)から階層L+1上のoverlapするnodes(最大12nodes で24MiB)をmergeする処理でfan-outが多い場合にIOが4倍に悪化 mergeのスケジューリングを改善したhyperleveldb  https://github.com/rescrv/HyperLevelDB }  6 R1: Emerging Hardware 担当:山室健
  • 7. Improving Flash Write Performance by Using Update Frequency }  データ配置policyは分析結果を基に構築 }  1. update頻度推定は同pageへの書き込み間隔を利用したLRUベースの MultiLogと、正確な頻度情報を仮定したMultiLog-Oracle }  2. 分析結果から得たGCのoverheadコスト関数(式(11))からupdateの際に promotion判定、GCの際にdemotion判定を実施 }  3. GCのpolicyは最後に書き込みが行われたblockを採用するLRUベース }  block内の有効page数が少ないものを選択するGreedyな手法に比べて性能の劣化は少なく、 メタ情報を管理する余剰領域もいらないため実現が容易 論文内Fig.4から引用 7 R1: Emerging Hardware 担当:山室健
  • 8. Improving Flash Write Performance by Using Update Frequency }  実験概要 }  実験はTPC-C[24]とNokia TATP[19]のDBベンチマークを利用  →書き込みが多いworkloadを想定 }  }  }  page sizeは4kB/erase blockは64pagesの100GB SSDを想定 予備ブロック割合αとGC overheadの関係を評価 比較手法はNaiveなLRU/Greedyと、既存手法[14][26][12]の3パタン 論文内Fig.7から引用 8 R1: Emerging Hardware 担当:山室健