- Kengo_TODA
- 1001
- 0
- 0
- 0
org.apache.cassandra.db.commitlog.CommitLogHeader.java読んでる。これdirtyフラグをBitSetに持ってるけど、MemtableがFlushされるごとにCommitLogも読込→更新→書込されるのか?
2011-05-31 07:11:53cloneMeShallow()ってメソッド名は面白いな。動詞というより命令文っぽい雰囲気がある。が、単なるclone()よりだんぜん処理内容が分かりやすい。なんで参照複製じゃダメなの?という疑問は残るが……。
2011-05-31 07:14:22意図を表すコメントが多くてIDEなしでもかなり読みやすい反面、IF-ELSEにブロック使ってなかったり改行位置がC言語っぽかったりして、Eclipse使ってはいないんじゃないかなという感じだ。テキストエディタで頑張る人?
2011-05-31 07:17:21`columnFamilies.get(partitioner.decorateKey(key))`とかすばらしく分かりやすいコードだ。
2011-05-31 07:32:50読んでる。推測わりと当たり?ランダムライト想定&ログ書込はシングルスレッド&ログバッファなし、ってことを考えると、一般的なRDBMSより重そうな印象だ。 / ArchitectureCommitLog - Cassandra Wiki http://t.co/ae5QtEx
2011-05-31 07:42:30となると最大の差は”the first insert to a given ColumnFamily CF in each CommitLogSegment”が発生する頻度、か?
2011-05-31 07:56:46あとREDOログはファイルサイズ変更を伴わない線形上書きだけど、Commitログの実体はRandomAccessFileなんでファイルサイズ変更を伴う(基本的には)線形上書きになる。
2011-05-31 07:59:33ファイルシステムが領域確保に走ったりメタデータを書き換えたりすることを考えると、fdatasync()使ってまでI/Oコストを減らそうとしているRDBMSよりはI/Oリッチだと言えるんじゃないかなこれ
2011-05-31 08:00:18あとRandomAccessFileを拡張したBufferedRandomAccessFileを作っているらしく、Commitログにもバッファがあると言っていい。 #cassandra_reading
2011-05-31 08:03:31ミドルウェアのコード読むのは面白いもんだ、h2databaseは記憶領域の管理が入り組んでて挫折したけど、Cassandraなら比較的シンプルだし基本的なアーキテクチャもだいたいわかるし。 参考:http://t.co/cv9KXQv
2011-05-31 08:06:03んー恐れていたほどランダムライトが出るわけじゃないけど、DirtyじゃないColumnFamilyのUpdateが走ると毎回ヘッダをまるごと書き換える実装か……これはループの外に出せるし、そもそもシングルスレッドなんだから更新bitが含まれるセクタだけ書き換えればよさそうだ。
2011-05-31 08:19:05あとヘッダを更新するごとにCommitLogHeader#toByteArray()を実行しててこれがまたDataOutputStreamなんぞを使っているのでヘッダの更新はかなりコスト高に見える。 #cassandra_reading
2011-05-31 08:21:14latest stableのコードを読んでたのでもしやと思って0.8.0rc1を落としてきたら案の定ヘッダの書き換えは少なくなっているようだ……というかCommitLogHeader.javaが空ファイルになっとる #cassandra_reading
2011-05-31 08:26:01DirtyフラグをBitSetじゃなくてHashSet<Integer>で記録するようになったのか。さらにメモリリッチに……と思ったが純粋に「汚れているCFの数」が容量に寄与するようになったので有利なケースも多そうだ。 #cassandra_reading
2011-05-31 08:29:300.7以降でのCommitLogの書込はデータ更新と完全に非同期のようだ。ソースも色々読んでみたがCallable/Runnableにconcurrentパッケージを使ったわりと一般的な実装だった。 http://t.co/iaw5iqZ.7 #cassandra_reading
2011-05-31 11:06:52