act-act about projects rss

CouchDB Source Code Reading part1

Why CouchDB?

数年前にCouchDBのデータフォーマットについて解説しているページを読みました。CouchDBの内部ではデータをB+treeで保持しており、且つデータはappend onlyでMVCCである、という部分が面白くて、その時からCouchDBに興味がありました。しかしコードがErlangで書かれており、当時の私にはCouchDBのコードを読むことができませんでした。

1年ほど前からErlangのコードにちょっとずつ触れるようになり、CouchDBのコードも時間をかければ読めるような気がするので、気が向いた時にちょっとずつ読んでいこうと思います。

本当はある程度読んでまとめてからアウトプットしようと思っていたのですが、正直言ってかなり苦戦していて、まとめられる気がしなくなったので、読んだところからダラダラと書いていくことにしました。ですので、続かないかも。

Source

githubのapache/couchdbのmasterのコードを読んでいきます。

https://github.com/apache/couchdb

Data File

実際にCouchDBを動かしてみると、CouchDBのデータファイルは、データベースに対して1:1で作成されているようです。–prefix等を指定せずにmake && make installすると、データファイルは/usr/local/var/lib/couchdb/(database).couchに作成されます。1ファイルしか生成されないことに不安があるものの、コードを読んでいくうちにファイルの分割とかあると思うので、気にしないことにします。

データファイルのオープンは以下で行われています。

couch_db_updater.erl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
init({MainPid, DbName, Filepath, Fd, Options}) ->
    process_flag(trap_exit, true),
    case lists:member(create, Options) of
    true ->
        % create a new header and writes it to the file
        Header =  #db_header{},
        ok = couch_file:write_header(Fd, Header),
        % delete any old compaction files that might be hanging around
        RootDir = couch_config:get("couchdb", "database_dir", "."),
        couch_file:delete(RootDir, Filepath ++ ".compact");                                                    
    false ->
       case couch_file:read_header(Fd) of
        {ok, Header} ->                                                                                             
            ok;
        no_valid_header ->
            % create a new header and writes it to the file
            Header =  #db_header{},
            ok = couch_file:write_header(Fd, Header),
            % delete any old compaction files that might be hanging around
            file:delete(Filepath ++ ".compact")
        end
    end,
    ReaderFd = open_reader_fd(Filepath, Options),                                                                   
    Db = init_db(DbName, Filepath, Fd, ReaderFd, Header, Options),
    Db2 = refresh_validate_doc_funs(Db),      
    {ok, Db2#db{main_pid = MainPid}}.

Optionsにcreateがある場合は空のヘッダを作成してファイルに書き込んでいます。そしてコンパクション時にデータを書き出すファイル(.compact)を削除しています。

Optionsにcreateがない場合はcouch_file:read_header/1で一旦ヘッダを読み込みますが、正常に読み込めることを確認したらopen_reader_fd/2で再度データファイルを読み直し、init_db/6でDBを扱う為の準備をします。

couch_file.erl

1
2
3
4
5
6
7
read_header(Fd) ->
    case gen_server:call(Fd, find_header, infinity) of
    {ok, Bin} ->
        {ok, binary_to_term(Bin)};
    Else ->
        Else
    end.  

couch_file:read_headerを読み進めてみます。と言ってもgen_server:call/3でヘッダをバイナリで受け取り、binary_to_term/1でTermに変換して返しているだけです。

couch_file.erl

1
2
handle_call(find_header, _From, #file{fd = Fd, eof = Pos} = File) ->
    {reply, find_header(Fd, Pos div ?SIZE_BLOCK), File}.  

このリクエストを受け取っているのは、先ほどのread_header/1と同じくcouch_fileモジュールです。Fileは、同モジュールのinit/1で生成されており、PosにはEOFのポインタが設定されています。find_header/2load_header/2を呼び出します。

couch_file.erl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
load_header(Fd, Block) ->
    {ok, <<1, HeaderLen:32/integer, RestBlock/binary>>} =
        file:pread(Fd, Block * ?SIZE_BLOCK, ?SIZE_BLOCK),
    TotalBytes = calculate_total_read_len(5, HeaderLen),
    case TotalBytes > byte_size(RestBlock) of
    false ->
        <<RawBin:TotalBytes/binary, _/binary>> = RestBlock;
    true ->
        {ok, Missing} = file:pread(
            Fd, (Block * ?SIZE_BLOCK) + 5 + byte_size(RestBlock),
            TotalBytes - byte_size(RestBlock)),
        RawBin = <<RestBlock/binary, Missing/binary>>
    end,
    <<Md5Sig:16/binary, HeaderBin/binary>> =
        iolist_to_binary(remove_block_prefixes(5, RawBin)),
    Md5Sig = couch_util:md5(HeaderBin),
    {ok, HeaderBin}.

load_header/2では、データファイル内の最後のブロックの先頭から読み始めています。実際にデータファイルの最後のブロックを見ると以下のようになっています。

0002000: 0100 0000 5ab1 66f1 2aec 7d5a 34e4 5969  ....Z.f.*.}Z4.Yi
0002010: 5a1f 8b30 4a83 680b 6400 0964 625f 6865  Z..0J.h.d..db_he
0002020: 6164 6572 6106 6102 6100 6803 6200 0010  adera.a.a.h.b...
0002030: cd68 0361 0161 0061 7161 9a68 0362 0000  .h.a.a.aqa.h.b..
0002040: 1167 6101 616b 6400 036e 696c 6100 6400  .ga.akd..nila.d.
0002050: 036e 696c 6400 036e 696c 6200 0003 e8    .nild..nilb....

load_header/2の最初の行で、ヘッダ部を読み込んでいる。先頭1バイトは「1」固定、次の4バイトはヘッダのサイズ(90byte)、その次の16バイトはMD5の値、残りの部分はヘッダを表現するErlang termsとなります。この最後の部分がread_header/1の中のbinary_to_term/1によって変換され、以下のrecordになります。

couch_db.hrl

1
2
3
4
5
6
7
8
9
10
11
12
reecord(db_header,
    {disk_version = ?LATEST_DISK_VERSION,
     update_seq = 0,
     unused = 0,
     fulldocinfo_by_id_btree_state = nil,
     docinfo_by_seq_btree_state = nil,
     local_docs_btree_state = nil,
     purge_seq = 0,
     purged_docs = nil,
     security_ptr = nil,
     revs_limit = 1000
    }).

update_seqは恐らくヘッダが書き換わることにインクリメントされていく値だと思います。fulldocinfo_by_id_btree_stateがドキュメントを格納するB+tree、docinfo_by_seq_btree_stateがドキュメントの最新シーケンス番号?のB+treeだと思います。このヘッダの各値は、今後読み進めていく中で確認していきます。

Conclusion

まずはデータファイルのヘッダの読み込み処理を読んでみました。Erlangはバイナリの読み込みが簡潔に書けるのが良いですね。