博士

やっほー、ロボ子！FileDBっていうキーバリューストアのZig実装が出たみたいじゃぞ！RiakのBitcask論文に触発されたって書いてある。

ロボ子

Bitcaskですか、博士。それは興味深いですね。FileDBは、レコードメタデータをログ構造化ハッシュテーブルに保存し、レコードを追記専用モードで挿入するために、1つのディスクファイルを並行して開いたままにするとのことです。

博士

そうそう！`MAX_FILE_REACHED`に達すると、ディスクファイルがローテーションされるんじゃって。古いファイルは読み取り用に開いたままになるらしいぞ。

ロボ子

`config.compactionInterval`秒ごとに実行されるコンパクションプロセスが、すべてのディスクファイルを読み取り、それらを1つのファイルに結合し、メタデータハッシュテーブルを更新するんですね。

博士

その通り！あと、`config.syncInterval`ごと、または`config.alwaysFsync`がTrueの場合はリクエストごとに、同期プロセスがオープンディスクファイルを同期するらしいぞ。データの安全性を保つための工夫じゃな。

ロボ子

なるほど。メソッドも色々あるみたいですね。`init`、`deinit`、`put`、`get`、`delete`、`list`、`sync`、`storeHashMap`、`loadKeyDir`…基本的な操作は全部揃っているようです。

博士

`put`でキーバリューペアを挿入して、`get`で取得、`delete`で削除…シンプルで使いやすそうじゃな。`list`でキーの一覧を取得できるのも便利じゃ。

ロボ子

Redis互換のクライアントが利用可能とのことですので、既存のRedisユーザーも移行しやすいかもしれませんね。

博士

ふむふむ。Redisベンチマークの結果も載ってるぞ。`redis-benchmark -p 6379 -t set -n 10000 -r 100000000`だと、スループットは13736.26 requests per second、レイテンシは平均3.615 msecじゃと。

ロボ子

SETのベンチマークですね。スループットは悪くないですが、レイテンシはもう少し改善の余地があるかもしれません。

博士

`redis-benchmark -p 6379 -t get -n 1000000 -r 1000000000 --threads 10`だと、スループットは104876.77 requests per second、レイテンシは平均0.405 msecじゃと。GETはかなり速いみたいじゃな。

ロボ子

GETはスループットも高く、レイテンシも非常に低いですね。読み込み性能はかなり優秀と言えそうです。

博士

FileDB、なかなか面白そうじゃな。Zigで書かれてるってのもポイント高いぞ！

ロボ子

ええ、私もそう思います。博士、今度FileDBを使って何か面白いプロジェクトを試してみませんか？

博士

いいのじゃ！ところでロボ子、FileDBって名前、ちょっとファイルっぽいけど、データベースなのじゃ。まるで、ファイルとデータベースのハーフみたいじゃな！

ロボ子

博士、それは…ただの語呂合わせだと思いますよ。