1

私はAWS Redshiftを使用して分析クエリを実行しています。クエリは計算を実行し、キーの値を更新します。この結果は、非同期クライアントが消費するキューシステムにエクスポートされます。しかし、キューイングシステムは順序を保証しないので、順序を決定するメカニズムが必要です。 "update_version"列のようなものが必要です。この列は、各更新操作で増分されます。これはoptimistic lockingに類似したものです。redshiftで行レベルのバージョン管理を行う方法は?

これを赤方偏移でどのように達成できますか?

タイムスタンプを使用する方法もありますが、タイムスタンプがクラスタ内の個々のノードからフェッチされるため、信頼性が低く、clock skewになりがちです。

グローバルオーダーは必要ありません。

注:この質問の範囲外のさまざまな問題があるため、注文キューを使用することを推奨しないでください。

+0

2つのプロセスが同時にキーの値を更新していた場合、なぜもう一方のプロセスが正しいのでしょうか?言い換えれば、あなたのキューワーカーが最近処理されたメッセージより新しいメッセージを投げ捨てた場合、クロックスキューの違いは何ですか? – systemjack

+1

また、特定のデータポイントの値が複数のノードにまたがっている場合でも、更新クエリを実行するように選択されたワーカーノードのクロックだけがカウントされます。所与の更新についての様々なノード・ストアにわたるすべてのタイムスタンプ値は同一である。 – systemjack

答えて

1

あなたは、次のいずれかの操作を実行できます。UPDATEがあなたのテーブルに、より破壊的であるINSERT INTO my_table SELECT *, update_version = N FROM my_table;

  • 実行UPDATE my _table SET update_version = update_version+1;
  • ファイル名を指定して実行(既存のデータ範囲となり、ますますソートされていない)だけに簡単にクエリ。 INSERTは、破壊されにくい(新しいデータはソートされていない領域に追加され、既存のデータは影響を受けません)が、現在の値だけを探す必要がある場合はクエリするのが難しくなります。

    あなたがUPDATE戦略を使用したいが、あなたは歴史を気にした場合は、更新を実行する前に、あなたがに現在の行の値を書き込むmy_table_historyテーブルを検討すべきです。

関連する問題