記事ではあんまり明確じゃないけど、私の考えでは、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がリソースを大量に消費しているのがわかるよ。その混乱を減らすことで、書き込みが多いサーバーからもっとパフォーマンスを引き出せるようになるんだ。

経験から言うと、Postgres（例えば）を使うと、個別の挿入やバッチ挿入でシステムの使用がひどくなるのは簡単だよ。NVMeドライブはしばしば極端に過小利用されていて、ボトルネックは全体のfsyncレイヤーなんだ。次に、耐久性はfsyncと同じだよ。クライアントは、両方のWAL書き込みが完了した場合にのみ成功が報告される。これはfsyncと同じ保証だけど、fsyncのボトルネックを回避することで、NVMeドライブの利点をより良く活用できるようになるんだ（I/Oをブロックするfsyncからリソースをシフトさせることができる）。そう、もっと管理が必要になるけど、今は同期fsync操作の代わりに2つの状態を維持する必要があるからね。でも、並列プログラミングのいいところは、もっと複雑だけど、同期ボトルネックを回避することでたくさんの利点が得られることなんだ。

OPの本当のポイントは、fsync()は現代のハードウェアの文脈ではクソだってことだ。数千のI/Oリクエストが同時に飛んでいるかもしれないからね。過度な直列化を導入せずに、書き込みが永続ストレージにコミットされることを保証するために、もっと細かいメカニズムが必要だよ。

記事にあるTigerbeatleの動画リンクを見ることをおすすめするよ。そこでビットロットや「fsyncゲート」、Postgresが30年間fsyncを間違って使ってたことについて話してる。純粋にエンタメとしてもすごく面白いよ。

データが本当にストレージメディアにあることを確信したいなら、fsyncを避けることはできない。 それは違うよ。io_uringはO_DIRECT書き込みリクエストをちゃんとサポートしてるからね。キャッシュをバイパスするのは、ただフラッシュするのとは違う（それがfsyncのすること）。だから設計に影響が出る。でもデータベースエンジンは、io_uringの機能セットのターゲットだから、この複雑さを管理することが期待されてるんだ。

データベースが役立つための耐久性保証を失うことになる。... データはまだカーネルバッファに残っていて、安定したストレージに書き込まれていないかもしれない。 > いや！それはfsyncを使うのをやめたからだよ。君のコードが非同期であることとは関係ない。OPはio_uringのサブミッションキューにデータを投げ込んで、その時点で「完了」としていたように聞こえる（つまり、io_uringの完了キューが完了を示すのを待っていない）。だから、fsyncは必要だけど、成功を示す前にカーネルが書き込みを始めるのを待ってさえいなかったんだ。ある程度、io_uringには完了の概念があるから混乱していると思うけど、OPは彼らのデュアルWALデザインにも別の完了の概念を持っている（彼らが「完了」WALと呼ぶ2つ目のWAL）。でも、OPがio_uringの完了を無視したことから正しい理解を得られたかは疑問だね。彼らは5ステップの手順を作って、io_uringの完了を1つチェックするけど、もう1つは省略している。 > 1. 意図レコードを書き込む（非同期） > 2. メモリ内で操作を行う > 3. 完了レコードを書き込む（非同期） > 4. 完了レコードがWALに書き込まれるのを待つ > 5. クライアントに成功を返す 意図レコードのio_uring完了を待っていないことに注意してね（そして、fsyncや代替手段についての言及もまだないから、これも間違ってる）。独立したio_uring間には順序保証がない（OPは各WALに対して別々のio_uringインスタンスを使っていると言ってるし）、同じio_uring内でも完了に関する順序は限られている（IOSQE_IO_LINKは存在するけど、サブミッションの境界を越えることはできないから、ここでは機能しない。OPは作業を別々のタイミングで提出しているからね）。彼らはIOSQE_IO_DRAINを使う必要があると思うけど、これだと書き込みが効果的に直列化されることになる。だから、OPは実際に意図の書き込みの完了を待つ必要があるように思う。