Voltdbのコマンドログについて読みました。コマンドログは、先行書き込みログのように各行の変更ではなく、トランザクションの呼び出しを記録します。呼び出しのみを記録することにより、コマンドログは最小限に抑えられ、ディスクI/Oがパフォーマンスに与える影響を制限します。
Voltdbがコマンドログを使用する理由と、Postgres、MySQL、SQLServer、Oracleなどの標準SQLデータベースが先行書き込みログを使用する理由の背後にあるデータベース理論を誰かが説明できますか？
13573 次
6 に答える
82
言い換えた方がいいと思います。
新しい分散VoltDBが先行書き込みログよりもコマンドログを使用するのはなぜですか？
実験をして、独自のストレージ/データベース実装を作成することを想像してみましょう。間違いなく、あなたはファイルシステムを抽象化し、いくつかの追加の最適化とともにブロックストレージを使用するのに十分進んでいます。
いくつかの基本的な用語：
- 状態：特定の時点で保存された情報
- コマンド：状態を変更するためのストレージへのディレクティブ
したがって、データベースは次のようになります。
次のステップは、いくつかのコマンドを実行することです。
いくつかの重要な側面に注意してください。
- コマンドは多くの保存されたエンティティに影響を与える可能性があるため、多くのブロックがダーティになります
- 次の状態は、現在の状態とコマンドの関数です
代わりにコマンドのチェーンがあれば十分なので、一部の中間状態はスキップできます。
最後に、データの整合性を保証する必要があります。
- ログ先行書き込み-中心的な概念は、永続ストレージへの大量の更新の前に状態の変更をログに記録する必要があるということです。私たちのアイデアに従って、各ブロックの増分変更をログに記録できます。
- コマンドロギング-中心的な概念は、状態を生成するために使用されるコマンドのみをログに記録することです。
どちらのアプローチにも長所と短所があります。先行書き込みログにはすべての変更されたデータが含まれます。コマンドログには追加処理が必要ですが、高速で軽量です。
コマンドロギングの鍵は、トランザクションの結果ではなく、呼び出しをログに記録することです。呼び出しのみを記録することにより、コマンドログは最小限に抑えられ、ディスクI/Oがパフォーマンスに与える影響を制限します。
その他の注意事項
従来のロールバックジャーナルは、元の変更されていないデータベースコンテンツのコピーを別のロールバックジャーナルファイルに書き込み、変更をデータベースファイルに直接書き込むことで機能します。
COMMITは、コミットを示す特別なレコードがWALに追加されたときに発生します。したがって、COMMITは、元のデータベースに書き込むことなく発生する可能性があります。これにより、リーダーは、変更が同時にWALにコミットされている間、元の変更されていないデータベースから操作を続行できます。
WALを使用すると、トランザクションによって変更されたすべてのデータファイルではなく、トランザクションがコミットされたことを保証するためにログファイルのみをディスクにフラッシュする必要があるため、ディスク書き込みの数が大幅に減少します。
ログファイルは順番に書き込まれるため、ログを同期するコストは、データページをフラッシュするコストよりもはるかに少なくなります。これは、データストアのさまざまな部分にアクセスする多くの小さなトランザクションを処理するサーバーに特に当てはまります。さらに、サーバーが多数の小さな同時トランザクションを処理している場合、ログファイルの1つのfsyncで多くのトランザクションをコミットするのに十分な場合があります。
結論
コマンドログ：
- より速い
- フットプリントが低い
- 「リプレイ」手順が重い
- 頻繁なスナップショットが必要
ログ先行書き込みは、原子性を提供する手法です。コマンドロギングのパフォーマンスが向上すると、トランザクション処理も向上します。1フィートのデータベース
確認
ARIESスタイルのログに対するコマンドログの利点の1つは、トランザクションを実行してログデータがディスクにフラッシュされるのを待つ代わりに、実行が開始する前にトランザクションをログに記録できることです。もう1つの利点は、コマンドログに必要なIOスループットが、コマンドの中継に使用されるネットワークによって制限されることです。Gig-Eの場合、このスループットは安価なコモディティディスクで満たすことができます。
VoltDBはその性質上配布されていることを覚えておくことが重要です。そのため、トランザクションの処理には少し注意が必要であり、パフォーマンスへの影響は顕著です。
VoltDBブログ：VoltDBの新しいコマンドロギング機能
VoltDBのコマンドログは、ストアドプロシージャの呼び出しとそのパラメーターで構成されています。ログは各ノードで作成され、すべての作業が複数のノードに複製されるため、各ログが複製されます。これにより、複製されたコマンドログが作成され、再生時に重複排除できます。VoltDBトランザクションは厳密に順序付けられているため、コマンドログには順序付け情報も含まれています。したがって、VoltDBが提供する完全なトランザクション分離を使用して、元のトランザクションが実行された正確な順序でリプレイを実行できます。呼び出し自体は変更されたデータよりも小さいことが多く、コミットされる前にログに記録できるため、このアプローチはパフォーマンスに非常に小さな影響を及ぼします。これは、VoltDBユーザーが、追加の耐久性保証を備えた、同じ種類の成層圏パフォーマンス数値を達成できることを意味します。
于 2013-01-10T14:58:22.237 に答える
2
Postgresの先行書き込みhttp://www.postgresql.org/docs/9.1/static/wal-intro.htmlとVoltDBのコマンドログ（あなたが参照した）の説明から、私はまったく違いを見ることができません。それは別の名前の同じ概念のようです。
どちらもログファイルのみをディスクに同期し、データは同期しないため、ログファイルを再生してデータを復元できます。
VoltDBのセクション10.4では、コミュニティバージョンにはコマンドログがないため、ACIDテストに合格しないと説明されています。Enterprise Editionでも、VoltDBがPostgesとして深刻です。
于 2013-01-09T03:57:44.143 に答える
2
WALを使用すると、リーダーはフラッシュされていないログのページから読み取ります。メインDBは変更されません。コマンドロギングでは、コマンドログから読み取ることはできません。
したがって、コマンドロギングは大きく異なります。VoltDBはコマンドロギングを使用してリカバリポイントを作成し、耐久性を確保しますが、それに付随するすべてのロックの問題などを伴い、メインのDBストア（RAM）にリアルタイムで書き込みます。
于 2016-02-03T19:34:39.690 に答える
0
私の読み方は次のとおりです:(私自身の意見）
ここで説明するコマンドログは、発生したトランザクションのみをログに記録し、トランザクション内またはトランザクションで発生したことはログに記録しません。さて、これが魔法のピースです...ロールバックする場合は、最後のスナップショットを復元する必要があります。その後、適用されたすべてのトランザクションを再生できます（上記のリンクで説明されています）。つまり、効果的にバックアップを復元し、すべてのスクリプトを再適用しているので、VoltDBだけがそれを自動化しています。
これで私が見る本当の違いは、通常のトランザクションログのように論理的に特定の時点にロールバックできないことです。通常のトランザクションログ（MSSQL、MySQLなど）は、トランザクションを「元に戻す」ことができるため、（正しい設定で）ある時点に簡単にロールバックできます。
興味深い質問が出てきます-pedzによるposを参照すると、コマンドログを使用しても常にACIDテストに合格しますか？もう少し読んでみます...
追加：もっと読んだのですが、これは非常に大きくて忙しいトランザクションデータベースには良い考えではないと思います。コマンドログがいっぱいになると、DBスナップショットが自動的に作成され、大きなトランザクションログとこれに使用されるIOからあなたを救いますか？スナップショットが定期的に実行されると、大量のIOが発生し、メモリも使用されます。アロス、私の見解では、最後の自動スナップショットの前の時点に簡単にロールバックする能力を失います-これは管理が非常に難しいと思います。
トランザクションシステムのトランザクションログに固執します。それは証明されており、機能します。
于 2013-01-10T09:47:49.990 に答える
0
それは本当に粒度の問題です。これらはストアドプロシージャのレベルで操作をログに記録し、ほとんどのRDBMSは個々のステートメントのレベル（および「下位」）でログを記録します。また、利点に関する彼らの宣伝文句は、少し赤いニシンです：
ARIESスタイルのログに対するコマンドログの利点の1つは、トランザクションを実行してログデータがディスクにフラッシュされるのを待つ代わりに、実行が開始する前にトランザクションをログに記録できることです。
コマンドがログに記録されるのを待つ必要があります。これははるかに小さなレコードです。
私が間違っていなければ、VoltDBのトランザクションの単位はストアドプロシージャです。従来のRDBMSは通常、任意の数のステートメントを含むアドホックトランザクションをサポートする必要があるため、プロシージャレベルのロギングは問題外です。さらに、ストアドプロシージャは、従来のRDBMSでは真に決定論的ではないことがよくあります（つまり、指定されたparams + log + dataは常に同じ出力を生成します）。これが機能するには、ストアドプロシージャが必要です。
それでも、この制約のあるRDBMSモデルでは、パフォーマンスが大幅に向上します。
于 2013-05-18T21:49:07.470 に答える
0
説明を始める前のいくつかの用語：
ロギングスキーム：データベースは、シャドウページング、先行書き込みログ（WAL）などのロギングスキームを使用して、同時実行性、分離、および耐久性を実装します（別のトピックです）。
WALが優れている理由を理解するために、シャドウページングの問題を見てみましょう。シャドウページングでは、データベースはデータベースのマスターバージョンとシャドウバージョンを使用するため、テーブルサイズが10億で、バッファープールマネージャーに、ダーティページのメモリ内のすべてのタプル（レコード）を保持するのに十分なメモリがない場合トランザクションがコミットされない限り、マスターバージョンには書き込まれません。
すべてのトランザクションがコミットされると、フラグが切り替えられ、シャドウバージョンがマスターバージョンになります。上の図にはPage 3 and Page 5、古いものがあり、ガベージコレクションが可能です。
このアプローチの問題は、ランダムに配置された多数の断片化されたタプルが残されていることです。これは、ダーティページに順次アクセスする場合に比べて遅くなります。これは、先行書き込みログが行うことです。
WALを使用するもう1つの利点は、実行時のパフォーマンス（ページをフラッシュするためにランダムなIOを実行していないため）ですが、回復時間が遅くなります。一方、シャドウページングを使用すると、回復パフォーマンスが高速になります（これはときどき必要になります）。
于 2020-09-15T03:35:53.437 に答える