問題タブ [idempotent]

REST に関するこのプレゼンテーション(タイムスタンプ 17:00-18:45) で、講演者は、HTTPPUTにはリソースのすべてのプロパティを含める必要があり、部分的な更新には使用しないと述べています。これは HTTP で必要です。それ以外の場合はべき等ではありません。

彼の冪等性の定義は次のとおりです (これは合理的に聞こえます)。

べき等とは、1 回または複数回実行でき、同じサーバー状態になる操作です。

ただし、彼は次に例を挙げます (言い換えると):

リクエスト A: を使用しPUTて、リソースの name プロパティのみを更新します。

リクエスト B: a を使用しPUTて、説明のみを更新します。

A と B の間で別のクライアントが名前を指定でき、要求 B の後、リソースには他のクライアントの名前と私の説明が含まれます。リクエスト A と B の後でサーバーの状態が同じではないため、これはべき等操作ではありません。

この解釈についてはよくわかりません。私にとって、冪等性は、同じ操作を連続して複数回実行したときに何が起こるかについてのみ教えてくれます。上記の例では、リクエスト A と B は 2 つの異なる操作であるため、A を実行してから B を実行しても特別な保証が必要であると考える理由はありません。特に、それらが一緒になってアトミック操作を構成する必要があると考える理由はありません。

リクエスト A を複数回実行すると、(B の場合も同様に) 1 回実行するのと同じ効果が得られるため、(これがPUT他の理由での不適切な使用であったとしても) 冪等であると考えたでしょう。

私の理解は間違っていますか？

(注: これはべき等性の意味に関する質問であり、 の適切な使用法ではありませんPUT)。

私は C# ドライバー (NuGet の v1.8.3) を使用していますが、$addtoSet/upsert操作によって実際に新しい項目が特定の配列に追加されたのか、それとも項目が既に存在していたのかを判断するのに苦労しています。

新しいアイテムの追加は、ドキュメントがまったく存在せず、アップサートによって作成されたばかりである場合と、ドキュメントは存在するが配列が存在しないか、指定されたアイテムが含まれていない場合の 2 つのケースに分類される可能性があります。

これを行う必要がある理由は、MongoDB にロードする大量のデータ セットがあり、処理中に壊れる可能性があるためです (すべきではありませんが、壊れる可能性があります)。これが発生した場合、ダウンストリーム処理を重複させずに最初からバックアップを開始できるようにする必要があります (処理を冪等に保ちます)。私のフローでは、項目が新しく追加されたと判断された場合、その項目のダウンストリーム処理をキューに入れます。ドキュメントに既に追加されていると判断された場合、それ以上のダウンストリーム作業は必要ありません。私の問題は、アイテムが配列に既に存在し、実際には何も変更されていない場合でも、呼び出しが 1 つのドキュメントを変更したという結果が常に返されることです。

C# ドライバー API に関する私の理解に基づいて、 を使用して呼び出しを行いWriteConcern.Acknowledged、 をチェックして、WriteConcernResult.DocumentsAffected実際にドキュメントが更新されたかどうかを確認できるはずです。

私の問題は、すべての場合において、書き込み懸念の結果が 1 つのドキュメントが更新されたことを返すことです。:/

これは、私のコードが呼び出しているドキュメントの例です。$addToSetこの特定のアイテムが「アイテム」リストに含まれている場合と含まれていない場合があります。

私のクエリは常に_id、処理メタデータに基づいて既知の値を使用します。

私の更新は次のとおりです。

空のコレクションに対してこのコードを 1 回実行すると、ドキュメントが追加され、期待どおりの応答が得られます ( DocumentsAffected = 1, UpdatedExisting = false)。再度 (何度でも) 実行すると、ドキュメントは変更されていないため更新されていないように見えますが、結果は予期しないものになりました ( DocumentsAffected = 1、UpdatedExisting = true)。

DocumentsAffected = 0ドキュメントが変更されていない場合、これは返されるべきではありませんか?

これらの呼び出しを 1 日に何百万回も行う必要があるため、このロジックをアイテムごとに複数の呼び出しに変えることをためらっています (最初にアイテムが指定されたドキュメント配列に存在するかどうかを確認し、次に追加/キューに入れるか、単にスキップします)すべて可能です。

これを1回の呼び出しで機能させる方法はありますか?

このフォルダがあるとします

このコマンドは Bash で実行できます

そしてそれは作成します

その後、結果を変更せずにコマンドを再実行できます。これを PowerShell でどのように行うことができますか?

最も洗練された Python の方法で達成したいこと: 特定のフィルターでデータベース内のオブジェクトを検索してみてください。結果がない場合にのみ、別のフィルターを使用してオブジェクトを見つけようとします。それでも結果が返されない場合は、オブジェクトが存在しないため、新しいインスタンスを挿入します。

私が考えていること：

このブロックが正しいのか、それとも私が達成しようとしていることを処理する最善の方法なのかはわかりません。

Apache Camel 2.13.1 を使用して、30 万行を超えるデータベース テーブルをポーリングしています。Idempotent Consumer EIPを使用して、既に処理された行をフィルタリングしようとしています。

ただし、実装が本当にスケーラブルかどうかは疑問です。私のラクダのコンテキストは次のとおりです:-

完全な 30 万行が 10 秒ごとに (consumer.delay パラメーターを介して) 処理されるように見えますが、これは非常に非効率的です。フィルターにフィードするクエリが既に処理された行のセットを利用できるように、パターンの一部としてある種のフィードバック ループを期待します。

ただし、CAMEL_MESSAGEPROCESSED テーブルの messageid 列には次のパターンがあります。

ここで、1908988 は request.body.ID です。EIP をキーオンに設定したため、クエリに簡単に組み込むことができません。

CAMEL_MESSAGEPROCESSED テーブルを select ステートメントへのフィードバック ループとして使用して、SQL サーバーがほとんどの負荷を実行するためのより良い方法はありますか?

アップデート：

そのため、奇妙なメッセージID列の値を引き起こしているのは私のognlコードであることがわかりました。それをに変更する

修正しました。これで、使用可能な messageId 列ができたので、'from' SQL クエリを

しかし、Idempotent Consumer EIP を破損していると思います。

他の誰かがこれをしますか？しない理由はありますか？

以下の更新された質問を参照してください。

元の質問:

私の現在の Rails プロジェクトでは、大きな xml/csv データ ファイルを解析し、それを mongodb に保存する必要があります。今、私はこの手順を使用します：

1. ユーザーからアップロードされたファイルを受け取り、データをmongodbに保存します
2. sidekiq を使用して、mongodb 内のデータの非同期処理を実行します。
3. 処理が完了したら、生データを削除します。

localhost の小規模および中規模のデータの場合、上記の手順は適切に実行されます。しかし、heroku では、hirefire を使用してワーカー dyno を動的に上下にスケーリングします。ワーカーがまだ大きなデータを処理しているときに、hirefire は空のキューを確認し、ワーカーの dyno をスケールダウンします。これにより、プロセスに kill シグナルが送信され、プロセスが不完全な状態のままになります。

解析を行うためのより良い方法を探しており、解析プロセスがいつでも強制終了され (kill シグナルを受信したときに現在の状態を保存する)、プロセスが再キューイングされるようにしています。

現在、私は Model.delay.parse_file を使用していますが、再キューイングされません。

アップデート

sidekiq wiki を読んだ後、ジョブ制御に関する記事を見つけました。コード、その仕組み、および SIGTERM シグナルを受信して​​ワーカーが再キューイングされたときに状態を保持する方法を説明できる人はいますか?

ジョブの終了を処理し、現在の状態を保存し、最後の位置から続行する別の方法はありますか?

ありがとう、

べき等とは、操作を N 回実行しても同じ結果が得られることを意味します

http://restcookbook.com/HTTP%20Methods/べき等性/

著者は、「これはリソース自体ではなく、結果にのみ適用される」と述べています。結果とリソースの違いは何ですか?

たとえば、本文が「hello」の PUT がメッセージ リソースを「hello」に更新するとします。次に、「さようなら」で PUT すると、「さようなら」に更新されます。ここでは 2 つの PUT があり、結果は同じではありません。1 回目はリソース値が「hello」で、2 回目は「さようなら」です。

私はDefining Idempotenceを読みましたが、その受け入れられた応答は同じ値のPUTでなければならないと言っているようです(たとえば、一般的なPUTメソッドではなく、べき等であるPUT "hello"を2回続けて)。

べき等メソッドへの繰り返しのリクエストは、同じ応答コードを返す必要がありますか?

他の多くの人が同じ質問をして、矛盾した答えに行き着いています。回答は、その問題に関する信頼できる情報源を参照する必要があります。

独自の要件ファイルを持つ python プロジェクトがあります。プロジェクトには独自の virtualenv もあり、パッケージの 1 つが「pyPdf」です。ライブラリにはバグがあり、バグを修正するパッチを書きました。

このファイルを pypdf.patch と呼びましょう。Linux patch コマンドを使用してパッチを実行します。

Idempotent プロパティを使用して 2 つのことを行うには、bash スクリプトを作成する必要があります (つまり、スクリプトを複数回実行することは、1 回実行することと同じである必要があります)。

1）さまざまなライブラリ要件（git + ssh要件を含むFlask == 0.10.1など）を含む要件ファイルを実行し、すべてのライブラリに対してpipインストールを実行します。

2) pypdf ライブラリにパッチを適用します。

この面でのリードに感謝します。「冪等性」に注意してください。

PS: 私の requirements.txt ファイルは次のようになります (ライブラリをインストールするために、virtualenv の下で pip install - r requirements.txt を実行します)。

ありがとう