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のよう。
- Data File(SSTable)
See also
ここの部分のアーキテクチャと実装は、Bigtableをinspireしてるそうなので、この論文の5.2, 5.3あたりはよく読んでおいたほうがよさそう。
http://labs.google.com/papers/bigtable.html
http://wiki.apache.org/cassandra/ArchitectureSSTable
- Bloom filterを後で調べる