act-act about projects rss

CouchDB Source Code Reading part10

前回、アタッチメントをファイルに書き込む箇所を読んだのですが、書き込んだデータがアタッチメントかどうかをどのように判別できるようにしているのか分からなかったので、アタッチメントをファイルから読み出す部分を見てみたいと思います。

Read attachement data from file

まずHTTPレイヤをエントリとし、GETメソッドを扱う関数を探してみたところ、couch_httpd_db:db_doc_req/3を見つけたので、ここから追っていきます。

couch_httpd_db.erl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
db_doc_req(#httpd{method = 'GET', mochi_req = MochiReq} = Req, Db, DocId) ->
    #doc_query_args{
        rev = Rev,
        open_revs = Revs,
        options = Options1,
        atts_since = AttsSince
    } = parse_doc_query(Req),
    Options = case AttsSince of
    nil ->
        Options1;
    RevList when is_list(RevList) ->
        [{atts_since, RevList}, attachments | Options1]
    end,
    case Revs of
    [] ->
        Doc = couch_doc_open(Db, DocId, Rev, Options),
        send_doc(Req, Doc, Options);
...

revopen_revsは指定しないケースで読み進めてみます。Revs[]の場合はcouch_doc_open/4を呼び出してドキュメントを取得しています。この関数を見ていきます。

couch_httpd_db.erl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
couch_doc_open(Db, DocId, Rev, Options) ->
    case Rev of
    nil -> % open most recent rev
        case couch_db:open_doc(Db, DocId, Options) of
        {ok, Doc} ->
            Doc;
         Error ->
             throw(Error)
         end;
  _ -> % open a specific rev (deletions come back as stubs)
      case couch_db:open_doc_revs(Db, DocId, [Rev], Options) of
          {ok, [{ok, Doc}]} ->
              Doc;
          {ok, [{{not_found, missing}, Rev}]} ->
              throw(not_found);
          {ok, [Else]} ->
              throw(Else)
      end
  end.

Revの指定がない(nil)場合はcouch_db:open_doc/3を呼び出しています。

couch_db.erl

1
2
3
4
5
6
7
8
9
10
11
12
13
open_doc(Db, Id, Options) ->
    increment_stat(Db, {couchdb, database_reads}),
    case open_doc_int(Db, Id, Options) of
    {ok, #doc{deleted=true}=Doc} ->
        case lists:member(deleted, Options) of
        true ->
            apply_open_options({ok, Doc},Options);
        false ->
            {not_found, deleted}
        end;
    Else ->
        apply_open_options(Else,Options)
    end.

couch_db:increment_stat/2以前読んでいるので簡単に書くと、{couchdb, database_reads}というkeyでETSにカウンタが登録されているので、それを更新しています。

couch_db:open_doc_int/3以前読んでいます。couch_db:make_doc/5の内容から、couch_db:read_doc/5couch_d:read_doc/2couch_file:pread_term/2という流れでファイルからデータを読み出し、couch_db:read_doc/2{ok, {BodyData0, Atts00}}という戻り値を返すことから、ドキュメント自体のデータとアタッチメントは{BodyData0, Atts00}としてシリアライズして保存されていることになります。

また、make_doc/5で取得したアタッチメントのリストをドキュメントの形式に直す際、#att.dataには{Fd, Sp}が設定されていることからcouch_db:make_doc/5でファイルから読み出したアタッチメントの情報には、実データではなくポインタしか保存されていないことが分かります。

そうなると、前回couch_db:doc_flush_atts/2にて、ファイルに書き込んだ際のポインタを#att.dataに設定する箇所があるはずです。couch_db:doc_flush_atts/2couch_db:flush_att/2の戻り値を#doc.attsに設定しているので、couch_db:flush_att/2が返す#att.dataに、アタッチメントデータをファイルに書き込んだ際のポインタが設定されることになります。

Write attachement data to file

前回と同様に、couch_db:flush_att/2when is_binary(Data)というガードがある関数を再度見てみます。

couch_db.erl

1
2
3
4
flush_att(Fd, #att{data=Data}=Att) when is_binary(Data) ->
    with_stream(Fd, Att, fun(OutputStream) ->
        couch_stream:write(OutputStream, Data)
    end);

この関数の戻り値の#att.dataに書き込んだデータのポインタが設定されていることになります。もう一度couch_db:with_stream/3を見てみます。

couch_db.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
27
28
29
30
31
32
with_stream(Fd, #att{md5=InMd5,type=Type,encoding=Enc}=Att, Fun) ->
...
    {StreamInfo, Len, IdentityLen, Md5, IdentityMd5} =
        couch_stream:close(OutputStream),
    check_md5(IdentityMd5, ReqMd5),
    {AttLen, DiskLen, NewEnc} = case Enc of
    identity ->
        case {Md5, IdentityMd5} of
        {Same, Same} ->
            {Len, IdentityLen, identity};
        _ ->
            {Len, IdentityLen, gzip}
        end;
    gzip ->
        case {Att#att.att_len, Att#att.disk_len} of
        {AL, DL} when AL =:= undefined orelse DL =:= undefined ->
            % Compressed attachment uploaded through the standalone API.
            {Len, Len, gzip};
        {AL, DL} ->
            % This case is used for efficient push-replication, where a
            % compressed attachment is located in the body of multipart
            % content-type request.
            {AL, DL, gzip}
        end
    end,
    Att#att{
        data={Fd,StreamInfo},
        att_len=AttLen,
        disk_len=DiskLen,
        md5=Md5,
        encoding=NewEnc
    }.

前回couch_stream:close/1までしか読みませんでしたが、今回はその先を読んでみます。

この関数の最後のところで#att.dataに対して、{Fd, StreamInfo}を設定しています。このStreamInfocouch_stream:close(OutputStream)を呼び出した戻り値に含まれる値です。この関数は、アタッチメントのデータバッファに残ったデータをファイルに書き込む、という処理で、StreamInfoは書き込んだデータの開始位置とサイズを[{Pos, BinSize}, {Pos, BinSize}, ...]という形式で保持しています。

このStreamInfo#att.dataに設定されていることによって、ドキュメントからアタッチメントのデータが取得できるようになっています。

Data block

一度見ていますが、改めてファイルからデータを読み込んでいる部分を見てみます。

couch_file.erl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
handle_call({pread_iolist, Pos}, _From, File) ->
    {RawData, NextPos} = try
        % up to 8Kbs of read ahead
        read_raw_iolist_int(File, Pos, 2 * ?SIZE_BLOCK - (Pos rem ?SIZE_BLOCK))
    catch
    _:_ ->
        read_raw_iolist_int(File, Pos, 4)
    end,
    <<Prefix:1/integer, Len:31/integer, RestRawData/binary>> =
        iolist_to_binary(RawData),
    case Prefix of
    1 ->
        {Md5, IoList} = extract_md5(
            maybe_read_more_iolist(RestRawData, 16 + Len, NextPos, File)),
        {reply, {ok, IoList, Md5}, File};
    0 ->
        IoList = maybe_read_more_iolist(RestRawData, Len, NextPos, File),
        {reply, {ok, IoList, <<>>}, File}
    end;

最初にcouch_file:read_raw_iolist_int/3で約8KB(2ブロック分)を読み込み、NextPosを取得しています。この関数と、この関数の中で呼び出しているcouch_file:calculate_total_read_len/2を見てみます。

couch_file.erl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
-spec read_raw_iolist_int(#file{}, Pos::non_neg_integer(), Len::non_neg_integer()) ->
    {Data::iolist(), CurPos::non_neg_integer()}.
read_raw_iolist_int(Fd, {Pos, _Size}, Len) -> % 0110 UPGRADE CODE
    read_raw_iolist_int(Fd, Pos, Len);
read_raw_iolist_int(#file{fd = Fd}, Pos, Len) ->
    BlockOffset = Pos rem ?SIZE_BLOCK,
    TotalBytes = calculate_total_read_len(BlockOffset, Len),
    {ok, <<RawBin:TotalBytes/binary>>} = file:pread(Fd, Pos, TotalBytes),
    {remove_block_prefixes(BlockOffset, RawBin), Pos + TotalBytes}.
...
calculate_total_read_len(0, FinalLen) ->
    calculate_total_read_len(1, FinalLen) + 1;
calculate_total_read_len(BlockOffset, FinalLen) ->
    case ?SIZE_BLOCK - BlockOffset of
    BlockLeft when BlockLeft >= FinalLen ->
        FinalLen;
    BlockLeft ->
        FinalLen + ((FinalLen - BlockLeft) div (?SIZE_BLOCK -1)) +
            if ((FinalLen - BlockLeft) rem (?SIZE_BLOCK -1)) =:= 0 -> 0;
                true -> 1 end
    end.

couch_file:read_raw_iolist_int/3の呼び出しでは、Lenは約8KB(2ブロック)、BlockOffsetはデータファイルのファイルポインタ(Pos)に対して、ブロックの先頭からのオフセットを求めています。これらをcouch_file:calculate_total_read_len/2に渡してファイルから読み込むサイズを決定し、ファイルの読み込みを開始したポイント(Pos)からそのサイズ分加算した数値を返します。これがNextPosになっています。

couch_file:calculate_total_read_len/2では、渡されたBlockOffsetから、そのオフセットからブロック終端までのサイズと、FinalLenで指定した読み出すサイズを比較しています。読み出すサイズ(FinalLen)がブロックオフセットからブロック終端までのサイズ、つまりそのブロック内に収まるのであればFinalLenを返します。収まらない場合はこの関数の最後の式になるのですが、(?SIZE_BLOCK -1)という値を使っている理由が良くわかりません。そこで前回追っていったブロック単位で書き込む箇所を再度確認します。

couch_file.erl

1
2
3
4
5
6
7
8
9
10
11
make_blocks(_BlockOffset, []) ->
    [];
make_blocks(0, IoList) ->
    [<<0>> | make_blocks(1, IoList)];
make_blocks(BlockOffset, IoList) ->
    case split_iolist(IoList, (?SIZE_BLOCK - BlockOffset), []) of
    {Begin, End} ->
        [Begin | make_blocks(0, End)];
    _SplitRemaining ->
        IoList
    end.

この関数を見ると、ブロックの先頭に<<0>>を設定しています。(?SIZE_BLOCK -1)の-1はこの分を意図しているようです。

最後にcouch_file:read_raw_iolist_int/3で約8KB読み込んだ後に呼び出すcouch_file:maybe_read_more_iolist/4を見てみます。

couch_file.erl

1
2
3
4
5
6
7
8
maybe_read_more_iolist(Buffer, DataSize, _, _)
    when DataSize =< byte_size(Buffer) ->
    <<Data:DataSize/binary, _/binary>> = Buffer,
    [Data];
maybe_read_more_iolist(Buffer, DataSize, NextPos, File) ->
    {Missing, _} =
        read_raw_iolist_int(File, NextPos, DataSize - byte_size(Buffer)),
    [Buffer, Missing].

Bufferは読み込んだ8KBの中の実データ部(RestRawData)、Lenは読み込んだ8KBの中で31bitで表現されるデータサイズです。RestRawDataのサイズ>=Len、つまり読み込み済みのデータにすべて収まっている場合は、RestRawDataの先頭からLenの長さ分だけ取って、Dataにバインドします。収まらない場合は、couch_file:read_raw_iolist_int/3を呼び出して収まらない分を読み込みます。

以上より、CouchDBは各データを以下の形式でファイルに読み書きしているようです。

couchdb_block

1ブロックは4KBで、データのポインタはブロック内に存在しています。先頭1bitはフォーマットレイアウト、その次の31ビットはデータサイズ、残りはtermをシリアライズしたバイナリデータです。

Conclusion

前回読んだアタッチメントのデータが、データファイル上でどのように識別されるか見てみました。

アタッチメントデータを表す識別子はデータファイルには書き込まれず、書き込んだデータファイルのファイルポインタを#att.dataに設定しているだけでした。これはファイルに書き込まれたデータそのものにはデータ種別を表す識別子が無くて、データ種別を表現するオブジェクトがそのファイルポインタを持つ、という管理をしていることになります。