SQLデータベースがコマンドログよりも先書きログを使用するのはなぜですか？
Voltdbの コマンドログ について読みました。コマンドログには、先行書き込みログのように各行の変更ではなく、トランザクションの呼び出しが記録されます。呼び出しのみを記録することにより、コマンドログは最小限に抑えられ、ディスクI/Oがパフォーマンスに与える影響が制限されます。
Voltdbがコマンドログを使用する理由と、Postgres、MySQL、SQLServer、Oracleなどの標準SQLデータベースが先行書き込みログを使用する理由の背後にあるデータベース理論について誰かが説明できますか？
私は言い換えると良いと思います：
新しい分散VoltDBが先行書き込みログではなくコマンドログを使用するのはなぜですか？
実験をして、独自のストレージ/データベース実装を作成することを想像してみましょう。間違いなく、ファイルシステムを抽象化し、ブロックストレージといくつかの追加の最適化を使用するのに十分な高度な知識があります。
いくつかの基本的な用語：
- 状態：ある時点で保存されている情報
- コマンド：状態を変更するためのストレージへのディレクティブ
したがって、データベースは次のようになります。
次のステップは、いくつかのコマンドを実行することです：
いくつかの重要な側面に注意してください：
- コマンドは多くの格納されたエンティティに影響を与える可能性があるため、多くのブロックがダーティになります
- 次の状態は、現在の状態とコマンドの関数です
代わりに一連のコマンドを用意するだけで十分なので、一部の中間状態はスキップできます。
最後に、データの整合性を保証する必要があります。
- 先行書き込みロギング-中心的な概念は、Stateの変更をログに記録することです永久ストレージへの重い更新の前。私たちの考えに従って、各ブロックの増分変更を記録できます。
- Command Logging-中心的な概念は、使用されるCommandのみをログに記録することです状態を生成します。
どちらのアプローチにも長所と短所があります。先行書き込みログには変更されたすべてのデータが含まれ、コマンドログには追加処理が必要になりますが、高速で軽量です。
コマンドロギングの鍵は、トランザクションの結果ではなく、呼び出しをログに記録することです。呼び出しのみを記録することにより、コマンドログは最小限に抑えられ、ディスクI/Oがパフォーマンスに与える影響が制限されます。
追記
従来のロールバックジャーナルは、元の変更されていないデータベースコンテンツのコピーを別のロールバックジャーナルファイルに書き込み、変更をデータベースファイルに直接書き込むことで機能します。
COMMITは、コミットを示す特別なレコードがWALに追加されたときに発生します。したがって、COMMITは元のデータベースに書き込むことなく発生する可能性があり、変更がWALに同時にコミットされている間、リーダーは変更されていない元のデータベースから操作を続行できます。
トランザクションによって変更されるすべてのデータファイルではなく、トランザクションがコミットされることを保証するためにログファイルのみをディスクにフラッシュする必要があるため、WALを使用すると、ディスク書き込みの数が大幅に削減されます。
ログファイルは順次書き込まれるため、ログを同期するコストは、データページをフラッシュするコストよりもはるかに低くなります。これは、データストアのさまざまな部分にアクセスする多くの小さなトランザクションを処理するサーバーに特に当てはまります。さらに、サーバーが多数の小さな同時トランザクションを処理している場合、ログファイルの1つのfsyncで多くのトランザクションをコミットするのに十分な場合があります。
結論
コマンドロギング：
- より速い
- 設置面積が少ない
- 「再生」手順が重い
- 頻繁なスナップショットが必要
先行書き込みロギングは、原子性を提供する手法です。コマンドロギングのパフォーマンスが向上すると、トランザクション処理も改善されます。 1フィートのデータベース
確認
ARIESスタイルのロギングに対するコマンドロギングの利点の1つは、トランザクションを実行してログデータがディスクにフラッシュされるのを待つのではなく、トランザクションを実行前にログに記録できることです。別の利点は、IOコマンドログに必要なスループットは、コマンドのリレーに使用されるネットワークによって制限されます。Gig-Eの場合、このスループットは安価な市販のディスクで満たすことができます。
VoltDBはその性質上、分散されていることを覚えておくことが重要です。そのため、トランザクションは少し扱いにくく、パフォーマンスへの影響は顕著です。
VoltDBのコマンドログは、ストアドプロシージャの呼び出しとそのパラメーターで構成されています。すべての作業が複数のノードに複製されるため、各ノードでログが作成され、各ログが複製されます。この結果、複製されたコマンドログが再生時に重複排除されます。 VoltDBトランザクションは強く順序付けられているため、コマンドログには順序付け情報も含まれます。したがって、VoltDBが提供する完全なトランザクション分離により、元のトランザクションが実行された正確な順序で再生を行うことができます。多くの場合、呼び出し自体は変更されたデータよりも小さく、コミットされる前にログに記録できるため、このアプローチはパフォーマンスに非常に小さな影響を与えます。つまり、VoltDBユーザーは、追加の耐久性保証により、同じ種類の成層圏パフォーマンス値を達成できます。
Postgresの先書き http://www.postgresql.org/docs/9.1/static/wal-intro.html の説明と（参照した）VoltDBのコマンドログからは、全然違いを見ます。それは別の名前の同じ概念であるように見えます。
どちらもログファイルのみをディスクに同期し、データは同期しないため、ログファイルを再生することでデータを回復できます。
VoltDBのセクション10.4では、コミュニティバージョンにはコマンドログがないため、ACIDテストに合格しないと説明されています。エンタープライズ版でも、トランザクション分離の詳細（例 http://www.postgresql.org/docs/9.1/static/transaction-iso.html ）が表示されず、 VoltDBがPostgesと同じくらい深刻であることを私に安心させます。
私の見方は次のとおりです。
ここで説明するコマンドロギングでは、トランザクションが発生したときにのみトランザクションがログに記録され、トランザクションで発生したトランザクションはログに記録されません。さて、これが魔法のピースです...ロールバックしたい場合は、最後のスナップショットを復元する必要があり、その後適用されたすべてのトランザクションを再生できます（上記のリンクで説明）。つまり、バックアップを復元してすべてのスクリプトを再適用すると、VoltDBだけが自動化してくれます。
これで私が目にする本当の違いは、通常のトランザクションログのように論理的に特定の時点にロールバックできないことです。通常のトランザクションログ（MSSQL、MySQLなど）は、トランザクションを「逆転」できるため、（正しい設定で）ある時点に簡単にロールバックできます。
興味深い質問が表示されます-pedzによるposを参照すると、コマンドログでも常にACIDテストに合格しますか？もう少し読みます...
追加：さらに読みましたか？これは、非常に大きくて忙しいトランザクションデータベースには適していないと思います。コマンドログがいっぱいになると、DBスナップショットが自動的に作成され、大きなトランザクションログとこれに使用されるIOを節約できますか？スナップショットが定期的に実行されると、大量のIOが発生し、メモリをすぐに使用します。 Alos、私の見解では、最後の自動スナップショットの前の時点に簡単にロールバックする能力を失います-これは管理が非常に難しくなると思います。
トランザクションシステムのトランザクションログに固執します。それは証明され、機能します。
それは本当に粒度の問題です。ストアドプロシージャのレベルで操作をログに記録します。ほとんどのRDBMSは、個々のステートメントのレベル（および「下位」）でログを記録します。また、アドバンテージに関する彼らの言い訳は、少し赤いニシンです：
ARIESスタイルのロギングに対するコマンドロギングの利点の1つは、トランザクションを実行してログデータがディスクにフラッシュされるのを待つのではなく、トランザクションを実行前にログに記録できることです。
彼らはコマンドがログに記録されるのを待たなければなりません。これは非常に小さなレコードです。
誤解しない限り、VoltDBのトランザクションの単位はストアドプロシージャです。従来のRDBMSは通常、任意の数のステートメントを含むアドホックトランザクションをサポートする必要があるため、プロシージャレベルのロギングは問題外です。さらに、ストアドプロシージャは、多くの場合、従来のRDBMSでは真に決定的ではありません（つまり、与えられたparams + log + dataは常に同じ出力を生成します）。これが機能するために必要です。
それでも、この制約されたRDBMSモデルのパフォーマンスは大幅に向上します。
WALでは、リーダーはフラッシュされていないログのページから読み取ります。メインDBは変更されません。コマンドロギングでは、コマンドログから読み取ることはできません。
したがって、コマンドのロギングは大きく異なります。 VoltDBは、コマンドロギングを使用してリカバリポイントを作成し、耐久性を確実に保証します。ただし、メインのDBストア（RAM）にリアルタイムで書き込みを行っています-すべての付随するロックの問題などがあります。