通常、トランザクションのコミットはどのように実装されますか? つまり、いくつかのバッファー キャッシング戦略 (単純な Guava キャッシュ) に応じて、BerkeleyDB データベースに永続化されるトランザクション ログ (またはさまざまなページ タイプの複数のログ) があるということです。トランザクションのコミット中に、トランザクション ログが読み取られ、データ ファイルに書き込まれます (現在、単一の書き込みトランザクションのみが許可されています)。
ただし、これらのコミットは重いため、ボトルネックのようです。
私の考え: トランザクション ログは、最初にコミット中にディスクにフラッシュされます (ただし、メモリにも保持されます)。次に、トランザクション ログからのレコードが 1 つずつ読み取られ、「通常の」データ ファイルに追加されます。その後、エントリはトランザクション ログから削除されます。これで、トランザクション ログがまだ存在する場合、新しい書き込みトランザクションを続行する前に、残りのエントリをデータ ファイルに書き込む必要があるという事実に基づいて、クラッシュしたトランザクションを再生できるはずです。
ただし、前述のように、やり直し操作が期待どおりに機能しないことに加えて、実際のデータページに加えて、ページ構造のような B+ ツリーの変更されたパス/ページもディスクに書き込む必要があるため、コミット自体がボトルネックです。
おそらく、スレッドプールの専用スレッドでコミットを発行し、今後のトランザクションで最初にトランザクションログのフラグをチェックして、トランザクションがコミットされているかどうかを示し、次に最初にトランザクションログから読み取り、次にデータから読み取りを試みることもできますファイル。
興味のある方: https://github.com/JohannesLichtenberger/sirix
私は現在、暇な時間を費やしてくれる他のオープンソース開発者も探しています ;-)
トランザクション システムの実装方法に関する文献はあまり見つかりませんでした。システムはバージョン管理をサポートしており、コミット後にのみ新しいバージョンを追加することに注意してください。
私の2番目のアプローチは機能していると思いますか? そうでなければ、「最先端」とは何ですか？ただし、実装が複雑すぎる場合は、最初は他のタスクを優先していると思います。
または、非同期コミットを提供することもできます... trx.asynchCommit() 非常に高速な更新を提供し、最終的には保存されたリビジョンへの読み取りアクセスを許可する必要があるアプリケーションに。ただし、別のトランザクションもコミットできるため、書き込みはシーケンシャルではない可能性がありますが、フラッシュディスクで使用するように設計されており、特にランダムな読み取りが発生しますが、書き込みは通常シーケンシャルです。