記事ではあんまり明確じゃないけど、私の考えでは、WALがディスクに書き込まれている間にメモリ内で更新できるから、メリットがあるんじゃないかな（フラッシュを待たずに進められるし）。だから、提示されているプロトコルには重要なステップが欠けてると思う：意図のレコードを書き込む（非同期）→ メモリ内で操作を実行 → 完了のレコードを書き込む（非同期）→ * * 意図と完了がディスクにフラッシュされるのを待つ * * クライアントに成功を返す

おそらく意図の記録は大きく（キーと値のデータを含む）て、完了記録は小さいと思うけど、必ずしもそうとは限らないよ。なぜなら、操作が意図ログに記録される順序とは異なる順序で完了することもあるからね。

私が理解する限り、著者は非同期書き込みが同期書き込みのような保証がないことを理解していて…それから非同期書き込みを2つの非同期書き込みに分けているんだけど…それでも同期版と同じような保証はないよね。だから、2つの非同期書き込みが全く保証になるとは思えない。単に、1つの非同期書き込みよりも一貫性が良くなるだけで、任意の時間が経過することを強制しているからって感じがする。

これは、クライアントがリクエストに対して成功を受け取ったとしても、その後システムがクラッシュした場合、再生したときにそのリクエストが記録されていない可能性があるということですか？ そうだね。OPは「意図の記録はカーネルバッファにただ座っているだけかもしれない」と言っているけど、同じ問題が完了記録にも当てはまる。だから、完了記録が耐久性のあるストレージに書き込まれるまで、クライアントに確認を発行することはできない。このブログ記事のポイントがよく分からないな。

WALとツリーを統合することは可能だよ。追加専用のBツリー実装もいくつかあるし。 https://github.com/Incubaid/baardskeerder

fsyncは、ドライブが書き込み成功を報告するのを待つんだよね。小さい書き込みをたくさんやると、fsyncがボトルネックになっちゃう。これはコンテキストスイッチやパイプラインの問題なんだ。非同期でデータを書き込むと、この確認を待つ必要がなくなるから、2つの非同期リクエストをダブルで書くことで、システムのCPUコアをうまく使えるようになるんだ。I/Oレスポンスを待っている間にストールしないからね。こういう方法を使うと、10倍のパフォーマンス向上が見られることも珍しくないよ。もちろん、両方のレコードが書き込まれたか確認して、クライアントに報告する必要があるけど、それは非fsyncリクエストだから、システムにかかる負担はfsyncの書き込みとは違うんだ。耐久性はfsyncの書き込みと同じくらいあるしね。ほとんどのデータベースは30年、40年前に作られたものだから、その頃はHDDが主流で、NVMEドライブなんて夢のまた夢だったんだよね。でも、ほとんどのDBは今でも同じように動いていて、NVMEドライブをHDDみたいに扱ってる。HDDでこの操作をやると、パフォーマンスが2倍になるけど、NVMEドライブなら簡単に10万IOPS出せるからね。もしNVMEドライブでデータベースの書き込みを監視してたら、そういうドライブが全然活用されてないのがわかると思う。だから、NVMEの能力をうまく活かすための新しいデータストレージレイヤーを開発する動きが増えてるんだよ（古いHDD時代のボトルネックを回避しようとしてる）。

真ん中の部分を見逃してると思うよ： ----------------- プロトコルはこうなる： 意図の記録を書く（非同期） メモリ内で操作を実行 完了記録を書く（非同期） クライアントに成功を返す ----------------- つまり、クライアントは両方のWALファイルが書き込まれるまで成功だと認識しない。目標は、最初の意図の記録でクライアントに早く応答を提供することではなく、システムがI/Oで待機しないようにすることなんだ。データベースに大量のデータを書き込むと、コアの書き込みではなく、I/O > fsyncがリソースを大量に消費しているのがわかるよ。その混乱を減らすことで、書き込みが多いサーバーからもっとパフォーマンスを引き出せるようになるんだ。