IRCで教えてもらった、ZFSでメモリ+SSD+HDDを統合して最大限の性能を発揮させようというもの。例えばこんな感じ。

http://blogs.sun.com/brendan/entry/test
http://blogs.sun.com/jonathan/entry/not_a_flash_in_the

L2ARCはLevel-2 と ARC(Adaptlive Replacement Cache)を合わせたもの。ARCはPostgreSQL8.0が出来る前にだいぶん勉強したのでほぼ知っている、ヒント無しだがランダムアクセスとシーケンシャルアクセス傾向にある程度最適化出来るインテリジェントなバッファキャッシュアルゴリズムだ。PostgreSQLではロック競合のためマルチプロセッサでの性能がふるわず、特許関係もあって外されてしまった。
ところが、ZFSでは見る限りARCを使っているようだ。wait-freeなARCを実装できるのなら、その方がいいだろう。

えっと、ざっくりコメントを読むと

- 従来のARCは、L1 cacheとして働く
- L2ARCはL2 cacheとして働くが、主にARCから追い出される予定のものを、別スレッドを立てて順次フェッチして書き込む。
- L2ARCはWrite-throughキャッシュであり、dirtyなデータは書き込まれない。

これと良く似たものを見たことがある。ReadyBoostだ。ReadyBoostはやはりwrite-throughキャッシュであり、上位下位のキャッシュ構造は異なったとしても、やっていることは（実現できることも）似たようなものだろう。つまり、頻繁にアクセスされるデータ部分のランダムリードを改善するのが目的だ。

例えばRDBMSにとってこれはどうかを考えよう。

- log
無意味。redo logはキャッシュヒットなど一切気にしない書き込みファイルである。
- 小さなテーブル/インデックス
頻繁にアクセスされる、読み込み専用テーブルには大変に効果があるだろう。書き込みが頻繁に行われるようなシーケンスなどには全くの逆効果。
- 大きなテーブル
メモリに乗っからない、しかしSSDに乗っかるようなテーブルやインデックスは、やや恩恵がある。同様に書き込みが多くなると意味がない。

こんなところだろうか。総じてホットスポットに対するチューニングとしては意味があると思うが。書き込み性能は総じていまいちに思える。

しかし、このようなことをつらつら考えるに、やはりファイルシステムには「ヒント」がなく、RDBMSは読み書き傾向がはっきりしているためヒントを実装しやすいにもかかわらず、それを生かせないところがもどかしいなぁ。それがすなわちお互いで同じようなキャッシュを作ってしまうゆえんなのだろうが。