問題タブ [eventual-consistency]

Google App Engine をバックエンドとして使用する認証システムがあります。基盤となる言語とフレームワークは、Java、JDO、Google 認証、Google App Engine で構成されています。

ユーザーエンティティがあります。ユーザー エンティティは、Google App Engine の認証応答から保存されたユーザー メタデータです (例: 名、姓、電子メール アドレス)。

ユーザーが登録またはログイン (どちらもサインイン イベント) を試みると、データストアをスキャンして、同じ電子メール アドレスを持つユーザーが既に存在するかどうかを確認します。ユーザーがまだ存在しない場合は、新しいユーザーを作成します。ユーザーが存在する場合は、ユーザー情報を更新して取得し、アプリケーション データを取得します。

ログイン ページはアプリケーション ページから完全に分離されているため、個別の複数のトランザクションを実行する必要があります。

ユーザーが短期間に 2 回登録しようとすると、重複したユーザーが作成される場合があります。最後に登録されたユーザーをいつでも取得できますが、クエリを一意の JDO クエリにする必要があります。一意の JDO クエリを使用すると、JDO クエリ (トランザクション内で実行) が (ユーザーの電子メール アドレスに対して) 2 つの同一の値が見つかったために失敗することがあります。

制約を適用するために、次の方法を検討しました。

1. 新しく登録されたユーザーの情報をキャッシュに保存します。キャッシュが重複を防ぐための適切なソリューションであることを示唆する情報は見つかりませんでした。キャッシュはマシン間ですぐに利用できますか? 存在する場合でも、キャッシュはさまざまな理由でエンティティを排出する可能性があります。
2. ユーザーの電子メールをセッションに保存します。これはコードを肥大化させ、制約を強制する奇妙な方法のように思われました。

認証ワークフロー中の値の重複を防ぎ、トランザクションを分離するための Google App Engine のベスト プラクティス アプローチはありますか?

ユニークなアイテムの販売データベースの場合、シーケンシャルな一貫性を使用すると、たとえば、そのユニークなアイテムが別の人に二重に販売されることがないことを保証できます。因果的一貫性はそれを保証するのだろうか?

同時に開始/終了したセールがある場合、システムが混乱することはありますか?

商品は一点ものですので、各商品1点のみの販売となります。

ありがとうございました

NoSQL 分散データベースについて何かを読むときはいつでも、CAP 定理に言及しています。これは、パーティション化されたシステムでは、完全な一貫性、完全な可用性、またはその両方のいずれかを実現できますが、完全に両方を実現することはできないことを意味します。

私にははっきりしていないのは、彼らが話している一貫性のタイプです。

1. 一部のクライアントが他のクライアントよりも古いデータを取得する可能性がある場合、データの鮮度の一貫性はありますか?
2. それとも、トランザクションが部分的にしか完了しない可能性があり、これによりデータが一貫性のない状態になる可能性があるという意味での一貫性ですか?

2 番目の解釈は、私には非常に危険に聞こえ、実際には受け入れられません。最初の解釈は受け入れられるように思えますが、データのセットを要求するクライアントに、一部が古いデータと一部が新しいデータが提供されないようにするにはどうすればよいでしょうか?

部分的な一貫性のみを提供することはどれほど危険であり、どのような悪影響が考えられるでしょうか?

バックエンド システムの負荷の処理に問題がある大企業で働いています。古いレガシー システム/データベースを置き換え、水平方向にスケーラブルな NoSQL データベースに置き換えることを検討しています。NoSQL データベースを検討する理由は、水平方向にスケーラブルなソリューションを使用して将来に備えるためです。

分散型 NoSQL データベースは通常、結果整合性のみを提供します。これがどの程度の問題なのかはまだ調査されていません。この場合、書き込み操作が比較的少なく、読み取り操作が多く、可用性が重要なシステムを扱っています。

非常に多くの NoSQL データベース システム (cassandra、mongoDB、hbase など) があります。どのデータベースシステムがどの場合に適しているかについてのガイドラインや文献はありますか? また、不整合の問題が発生する可能性と、この可能性を減らす方法とコストについても考えています。

文献への情報/ヒント/参照は大歓迎です。

いくつかのコレクションと約 30 のインデックスを持つ RavenDB があります。

DatabaseCommands.UpdateByIndex と PatchRequest を介して特定のコレクション (プロファイル) で一括更新を実行しようとしていますが、実際には私のコードは次のようなものです。

「Profiles/ ByFinder 」は、この特定のコレクションで機能するインデックスです。

奇妙なことは、このコマンドを実行すると、DB 内のすべてのインデックスが古い状態になることです。これは、プロファイル コレクションでまったく機能しないインデックスであっても同様です。

それはデフォルトの動作ですか?もしそうなら、それを回避する方法はありますか?

リードレプリカで Amazon MySQL RDS を使用することを検討しています。私を悩ませている唯一のものは、レプリカラグと最終的な不一致です. たとえば、ユーザーが自分のプロファイルを変更し (UPDATE はメイン DB インスタンスで実行されます)、ページを更新して変更された情報を表示する場合をイメージします (レプリカ ラグのためにまだ変更を受け取っていないレプリカから SELECT が実行される可能性があります)。

偶然、ターゲットを絞ったクエリを実行できることを述べているAmazon の記事を見つけました。私にとっては、レプリカではなくメイン DB インスタンスで選択を実行するように Amazon に指示するために、何らかのパラメータを追加できるように思えます。ユーザー プロファイルの例は非常に些細なことですが、ユーザーが複数の手順を実行し、次の画面で更新された情報を表示する必要がある場合など、より現実的なケース、たとえばチェックアウトでも同じ問題が発生します。はい、アプリケーションはそれ自体でデータ セット全体をキャッシュできますが、メインの DB インスタンスでターゲットを絞ったクエリを実行する方法を誰かが知っていれば、それは素晴らしいことです。

私は現在、Google-App-Engine ( https://www.udacity.com/course/ud859 )の udacity コースに取り組んでいます。プロファイルと会議があります。各プロファイルは会議に登録でき、プロファイル オブジェクトのリストに追加されます。

「getProfile」リクエスト (oAuth2.0 によって認証された現在アクティブなユーザーのユーザー データを取得する) の API エクスプローラーを見ると、「実行」をクリックするたびに異なる結果が得られます。

初めて実行をクリックすると、正しい応答が得られます。

正しい応答(開発者コンソールのデータストア クエリを使用してこれを検証しました):

しかし、もう一度実行をクリックすると、次の応答が返されます。

間違った応答

もう一度実行をクリックすると、正しい応答が得られます。常に間違っていることと正しいことが交互に繰り返されますが、データストア クエリ内のデータは同じままです。これは私にはまったく意味がありません。

getProfile メソッド:

更新 1: 12 時間経った今でも、問題は解決していません。開発者コンソールには正しいデータが表示されますが、フロントエンドと API Explorer は常に正しい結果と間違った結果を切り替えています。下に 2 つの異なるデータストアがあり、API 呼び出しがそれらの間で交互に行われているように感じます..?

更新 2:アプリを GAE の新しいプロジェクトに再デプロイしましたが、まだエラーが発生しています。問題が発生したときのより単純な例があるため、上記の投稿を変更しました。