Cassandraでのデータの書き込み

Cassandra code reading 3日目です。今日はデータの書き込み編です。ざーっと概要レベルで処理をおさえて、個々の細かいデータ構造は、追々追記していきます。

主要な登場人物は、

  • commit log
  • memtable
  • sstable

です。

commit log -> memtable -> sstable という順でデータは書かれるようです。

Commit Log (Disk)

パッケージでいうと、org.apache.cassandra.db.commitlog。

  • commit log (dist)にデータは書き出される。
  • commit logに書いた後に、適切なノードに送られる。
  • 各ノードは、local log中のwrite first recordsを受け取り、適切なmemtableを更新する
  • commit logは自信が保持しているcolumn familyが全てdiskに書き込まれたら削除される

Memtable (Memory)

  • memtableは、key/valueのペアをメモリ上で保持する。
  • memtableは、以下のタイミングでdiskにflushされる
    • 容量が不足したとき
    • メモリ数が多くなったとき(デフォルト設定では128個)
    • 時間がたった時
  • memtableは、commit logにコミットされた更新内容を記録するソート済みのバッファ

Memtable to SSTable(Disk)

  • SSTableはmemtableの内容を保存するときに利用されるファイルフォーマット
  • ソート済みでimmutableなファイル。
    • immutableなので、ファイルアクセス時にロックが不要。
  • memtableは、次の3つのファイルに書き出される。
    • Data File(SSTable)
      • SSTableは、Sorted Strings Tableの略で、key/valueのペアがkeyでソートされたファイル
    • Index File
      • (Key, offsset)のペアで、Data File中のポイントを指し示すもの
    • Bloom Filter
      • Cassandraはbloom filterをキーでのlookupを実行するときにIOを節約するために使っている。個々のSSTableは、bllom filterを持っていて、disk seekを行う前にチェックする。
      • bloom filterの意義について。
        • http://1978th.net/tech/promenade.cgi?id=70
        • ブルームフィルタとキャッシュ層とファイルDB層を一括してアトミックにゴニョゴニョするモジュールを作る必要があると書いてあるこの部分が、まさにCassandraのSSTableのよう。

See also

ここの部分のアーキテクチャと実装は、Bigtableをinspireしてるそうなので、この論文の5.2, 5.3あたりはよく読んでおいたほうがよさそう。

http://labs.google.com/papers/bigtable.html
http://wiki.apache.org/cassandra/ArchitectureSSTable

  • Bloom filterを後で調べる