SlideShare une entreprise Scribd logo
1  sur  13
Leveled Compactionについて

    株式会社INTHEFOREST
      関 あつお
Compactionとは
• memtable上のデータをflushしてSSTableを
  作成した後、他のSSTableとマージしてま
  と
  める機能
                    SSTable

            flush             marge
                    SSTable           SSTable
 memtable


                    SSTable
標準として使用されている Compaction
      SizeTiered Compaction

• 大体同じ大きさのSSTableが4つになった
  時
  これをマージして一つのSSTableを作成す
  る
SizeTiered Compactionの問題点
• 複数のSSTableに欲しいデータが点在する場合
  各SSTableを読み込まなければならない
• よくデリートされるデータは得に複数のSSTableにデータが存在する
  為
  多く読み込みに行かなければならない
• 巨大なSSTable同士のCompactionは重いし
  作業領域も大量に取らなければならない
1.0から登場した Leveled Compaction
•   Leveled Compaction は GoogleのLevelDBをベースに作られたCompaction
•   レベル0~8までの領域を使い、追加、更新されたデータを
    新しい順に若いレベルに保持する構造
•   レベルごとに保持しているキーの重複を無くす事で欲しいキーの情報など
    は
    レベルごとのSSTableを見るだけで済むようにしている
•   Compactionに必要な作業領域は繰り返すほど大きくはならず
    大体は設定するSSTableの大きさの10倍の領域 (sstable_size_in_mb * 10)
    で済みます
                         Level 1
            Level 0


                         Level 2

                         Level 3
Leveled Compaction の動き(1)
•   memtableからデータがflushされSSTableが作られた時、それをLevel 0として
    扱う
•   Level 0のSSTableは即座に CFのオプションで設定できるsstable_size_in_mbの
    量に分けられたりマージされたりして Level 1 に置かれる
    (sstable_size_in_mb の デフォルトは5MB)

                   Level 0
                                              Level 1
                             split or marge    3   2   1

           flush

memtable           SSTable
                                              Level 2

                                              Level 3
Leveled Compaction の動き(2)
•   レベル1として置かれたSSTableの合計がsstable_size_in_mb の 10倍に達し
    次に新しいキー、カラムのデータが入ってきた場合は古いデータ順に
    Level 1 のデータを Level 2 に置く



                          Level 1
         SSTable              5   4   3



                          Level 2
                      2   1



                          Level 3
Leveled Compaction の動き(3)
•   Level 2 はさらに10倍 (sstable_size_in_mb が 5 なら 500MB) にLevel 2 の
    SSTableの合計が達した場合、次はLevel 2 から Level 3 へデータが置かれる
•   Level 3 はさらに10倍 とLevelの許容量は10倍づつ上がっていく



                                 Level 1
          SSTable                 12 11   9



                                 Level 2
                         8   7    6   5   4   3   2



                                 Level 3
                    1
Leveled Compaction の動き(4)
•   レベルに入っているキーと同じキーのデータが入ってきた場合
    そのデータは同じSSTableにキーが重複されないようマージされる
•   また、データを入れると入ったLevelにあるSSTableはデータのバランスを
    取ったりする為、全体を更新する事が多々ある


     キー9と3が入った場合               Level 1               9はマージされ
        9   3                   9   3   12           3はレベル2にも存在してい
                                                     るがレベルが違うのでそのま
                                                     ま入る


                               Level 2
                        11 8    7   6   5    4   3



                               Level 3
                2   1
実際の使い方
• create column family (CF名) with
  compaction_strategy=LeveledCompactionStrategy and
  compaction_strategy_options={sstable_size_in_mb: (MB数)}

• update column family (CF名) with
  compaction_strategy=LeveledCompactionStrategy and
  compaction_strategy_options={sstable_size_in_mb: (MB数)}
SSTableのレベルを見るには
• SSTableを保持しているディレクトリに (CF名).json が
  あり
  SSTableの番号なんかが書かれてある
         中見はこんな感じ
  {
  "generations" : [ {
    "generation" : 0,
    "members" : [ ]
  }, {
    "generation" : 1,
    "members" : [ 13, 14, 15, 16, 17 ]
  }, {
    "generation" : 2,
    "members" : [ 11 ]
  }, {
    "generation" : 3,
    "members" : [ ]
  ~~~~~~~~~~~~~~~~~~~~~~~
個人的な懸念点
• compression_option でSSTableを圧縮する設定だと
  圧縮によっては各レベルのファイル数が爆裂
• 1.1.1のバージョンはレベル0のSSTableが
  処理されなかったりして増え続けるバグが存在
  (1.0.10だとFix済み)
ご清聴ありがとうございました

Contenu connexe

En vedette

Ocean base 破解数据库高可用难题
Ocean base 破解数据库高可用难题Ocean base 破解数据库高可用难题
Ocean base 破解数据库高可用难题everestsun
 
百度消息队列设计和实现总结
百度消息队列设计和实现总结百度消息队列设计和实现总结
百度消息队列设计和实现总结everestsun
 
Google LevelDB Study Discuss
Google LevelDB Study DiscussGoogle LevelDB Study Discuss
Google LevelDB Study Discusseverestsun
 
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考えるCassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考えるKazutaka Tomita
 
涨客资,用推策 推策产品介绍
涨客资,用推策 推策产品介绍涨客资,用推策 推策产品介绍
涨客资,用推策 推策产品介绍Baidu
 
Leveldb background
Leveldb backgroundLeveldb background
Leveldb background宗志 陈
 
The Anatomy Of The Google Architecture Fina Lv1.1
The Anatomy Of The Google Architecture Fina Lv1.1The Anatomy Of The Google Architecture Fina Lv1.1
The Anatomy Of The Google Architecture Fina Lv1.1Hassy Veldstra
 
Baidu
BaiduBaidu
BaiduNanor
 
The Missing Manual for Leveled Compaction Strategy (Wei Deng & Ryan Svihla, D...
The Missing Manual for Leveled Compaction Strategy (Wei Deng & Ryan Svihla, D...The Missing Manual for Leveled Compaction Strategy (Wei Deng & Ryan Svihla, D...
The Missing Manual for Leveled Compaction Strategy (Wei Deng & Ryan Svihla, D...DataStax
 
Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn
Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpnCassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn
Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpnhaketa
 

En vedette (14)

Ocean base 破解数据库高可用难题
Ocean base 破解数据库高可用难题Ocean base 破解数据库高可用难题
Ocean base 破解数据库高可用难题
 
百度消息队列设计和实现总结
百度消息队列设计和实现总结百度消息队列设计和实现总结
百度消息队列设计和实现总结
 
Google LevelDB Study Discuss
Google LevelDB Study DiscussGoogle LevelDB Study Discuss
Google LevelDB Study Discuss
 
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考えるCassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
 
Level db
Level dbLevel db
Level db
 
涨客资,用推策 推策产品介绍
涨客资,用推策 推策产品介绍涨客资,用推策 推策产品介绍
涨客资,用推策 推策产品介绍
 
Leveldb background
Leveldb backgroundLeveldb background
Leveldb background
 
Bigtable
BigtableBigtable
Bigtable
 
The Anatomy Of The Google Architecture Fina Lv1.1
The Anatomy Of The Google Architecture Fina Lv1.1The Anatomy Of The Google Architecture Fina Lv1.1
The Anatomy Of The Google Architecture Fina Lv1.1
 
Baidu
BaiduBaidu
Baidu
 
The Missing Manual for Leveled Compaction Strategy (Wei Deng & Ryan Svihla, D...
The Missing Manual for Leveled Compaction Strategy (Wei Deng & Ryan Svihla, D...The Missing Manual for Leveled Compaction Strategy (Wei Deng & Ryan Svihla, D...
The Missing Manual for Leveled Compaction Strategy (Wei Deng & Ryan Svihla, D...
 
Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn
Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpnCassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn
Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn
 
GOOGLE BIGTABLE
GOOGLE BIGTABLEGOOGLE BIGTABLE
GOOGLE BIGTABLE
 
The Google Bigtable
The Google BigtableThe Google Bigtable
The Google Bigtable
 

Leveled compaction

  • 1. Leveled Compactionについて 株式会社INTHEFOREST 関 あつお
  • 2. Compactionとは • memtable上のデータをflushしてSSTableを 作成した後、他のSSTableとマージしてま と める機能 SSTable flush marge SSTable SSTable memtable SSTable
  • 3. 標準として使用されている Compaction SizeTiered Compaction • 大体同じ大きさのSSTableが4つになった 時 これをマージして一つのSSTableを作成す る
  • 4. SizeTiered Compactionの問題点 • 複数のSSTableに欲しいデータが点在する場合 各SSTableを読み込まなければならない • よくデリートされるデータは得に複数のSSTableにデータが存在する 為 多く読み込みに行かなければならない • 巨大なSSTable同士のCompactionは重いし 作業領域も大量に取らなければならない
  • 5. 1.0から登場した Leveled Compaction • Leveled Compaction は GoogleのLevelDBをベースに作られたCompaction • レベル0~8までの領域を使い、追加、更新されたデータを 新しい順に若いレベルに保持する構造 • レベルごとに保持しているキーの重複を無くす事で欲しいキーの情報など は レベルごとのSSTableを見るだけで済むようにしている • Compactionに必要な作業領域は繰り返すほど大きくはならず 大体は設定するSSTableの大きさの10倍の領域 (sstable_size_in_mb * 10) で済みます Level 1 Level 0 Level 2 Level 3
  • 6. Leveled Compaction の動き(1) • memtableからデータがflushされSSTableが作られた時、それをLevel 0として 扱う • Level 0のSSTableは即座に CFのオプションで設定できるsstable_size_in_mbの 量に分けられたりマージされたりして Level 1 に置かれる (sstable_size_in_mb の デフォルトは5MB) Level 0 Level 1 split or marge 3 2 1 flush memtable SSTable Level 2 Level 3
  • 7. Leveled Compaction の動き(2) • レベル1として置かれたSSTableの合計がsstable_size_in_mb の 10倍に達し 次に新しいキー、カラムのデータが入ってきた場合は古いデータ順に Level 1 のデータを Level 2 に置く Level 1 SSTable 5 4 3 Level 2 2 1 Level 3
  • 8. Leveled Compaction の動き(3) • Level 2 はさらに10倍 (sstable_size_in_mb が 5 なら 500MB) にLevel 2 の SSTableの合計が達した場合、次はLevel 2 から Level 3 へデータが置かれる • Level 3 はさらに10倍 とLevelの許容量は10倍づつ上がっていく Level 1 SSTable 12 11 9 Level 2 8 7 6 5 4 3 2 Level 3 1
  • 9. Leveled Compaction の動き(4) • レベルに入っているキーと同じキーのデータが入ってきた場合 そのデータは同じSSTableにキーが重複されないようマージされる • また、データを入れると入ったLevelにあるSSTableはデータのバランスを 取ったりする為、全体を更新する事が多々ある キー9と3が入った場合 Level 1 9はマージされ 9 3 9 3 12 3はレベル2にも存在してい るがレベルが違うのでそのま ま入る Level 2 11 8 7 6 5 4 3 Level 3 2 1
  • 10. 実際の使い方 • create column family (CF名) with compaction_strategy=LeveledCompactionStrategy and compaction_strategy_options={sstable_size_in_mb: (MB数)} • update column family (CF名) with compaction_strategy=LeveledCompactionStrategy and compaction_strategy_options={sstable_size_in_mb: (MB数)}
  • 11. SSTableのレベルを見るには • SSTableを保持しているディレクトリに (CF名).json が あり SSTableの番号なんかが書かれてある 中見はこんな感じ { "generations" : [ { "generation" : 0, "members" : [ ] }, { "generation" : 1, "members" : [ 13, 14, 15, 16, 17 ] }, { "generation" : 2, "members" : [ 11 ] }, { "generation" : 3, "members" : [ ] ~~~~~~~~~~~~~~~~~~~~~~~
  • 12. 個人的な懸念点 • compression_option でSSTableを圧縮する設定だと 圧縮によっては各レベルのファイル数が爆裂 • 1.1.1のバージョンはレベル0のSSTableが 処理されなかったりして増え続けるバグが存在 (1.0.10だとFix済み)