1

私の Python Web アプリケーションはデータストアとして DynamoDB を使用していますが、これはおそらく、インデックスの一貫性がアプリケーション層で行われる他の NoSQL テーブルにも当てはまります。検索を容易にするために、データを非正規化し、いくつかのテーブルにインデックスを作成しています。

たとえば、私の users テーブルの場合:

* Table 1: (user_id) email, employee_id, first name, last name, etc ...
  Table 2: (email) user_id
  Table 3: (employee_id) user_id

表 1 は、ユーザー情報が格納される「プライマリ テーブル」です。user_id がわかっている場合、ユーザーに関するすべての情報を 1 回の GET クエリで取得できます。

表 2 と 3 では、email または employee_id によるルックアップが可能です。最初にこれらのテーブルにクエリを実行して user_id を取得し、次に表 1 に 2 番目のクエリを実行して残りの情報を取得する必要があります。

私の懸念は、正規化されていないデータにあります。一致するデータがテーブル 2 + 3 から確実に削除されるようにするために、テーブル 1 からの削除を処理する最善の方法は何ですか? また、インサートを確保しますか？

現在、私の一連のイベントは次のようなものです。

1. Insert row in table 1
2. Insert row in table 2
3. Insert row in table 3

最後に「チェック」を追加するのは理にかなっていますか? 何かのようなもの：

4. Check that all 3 rows have been inserted.
5. If a row is missing, remove rows from all tables and raise an error.

他のテクニックは？

4

2 に答える 2

2

簡単な答えは次のとおりです。一貫性を確保する方法はありません。これは、パフォーマンスとスケーラビリティと引き換えにNoSQLに移行するときに支払うことに同意した価格です。

DynamoDB マッパーには「トランザクション エンジン」があります。トランザクション オブジェクトはプレーンな DynamoDB アイテムであり、永続化することができます。このようにして、トランザクションとも呼ばれるアクションの論理グループが成功した場合、永続化されたステータスを確認することでそれを確認できます。しかし、そうではないことを確認する手段はありません...

ちょっとした宣伝をするために:)、dynamodb-mapperトランザクションエンジンがサポートしています

  • 単一/複数のターゲット
  • サブトランザクション
  • オブジェクトを作成するトランザクション (まだリリースされていません)

独自のマッパーを展開している場合 (これは楽しい作業です)、ソース コードを参照してください。

免責事項: 私は主要な dynamodb-mapper プロジェクトの 1 つです。お気軽に貢献してください:)

于 2012-09-10T14:33:29.257 に答える
0

免責事項: 私は実際に DynamoDB を使用したわけではありません。データ モデルと API を調べただけなので、これは価値があると考えてください。

あなたが与えているユースケースは、データ用の1つのプライマリテーブルであり、他のテーブルは手動でロールされたインデックス用です。これは、RDBMS での作業のように思えます (おそらく、拡張のためのシャーディングが必要です)。しかし、それがうまくいかない場合は、ここでいくつかのアイデアがうまくいくかもしれないし、うまくいかないかもしれません.

A. そのままにしておいてください。インデックス テーブルからデータを提供しない場合は、最初にプライマリ テーブルを処理する限り、遅延削除と挿入を行う余裕があるかもしれません。これが起こると言います：

1) Delete JDoe from Main table
xxxxxxxxxx Process running code crashes xxxxxxx
2) Delete from email index       // Never gets here
3) Delete from employee_id index // Never gets here

「電子メール」クエリが着信した場合、インデックスから対応する user_id を解決しますが (現在は古い)、メイン テーブルには表示されません。何かが間違っていることがわかっているので、失敗/エラーを返し、インデックスをクリーンアップできます。言い換えれば、古いデータと一緒に生活し、必要に応じてデータをクリーンアップして問題を回避できます。どの程度の古いデータが予想されるかを把握し、毎日何らかのハウスキーピングを行うスクリプトを作成する必要があります。

B. 本当にロックとトランザクションをシミュレートしたい場合は、ロックなどの共有リソースを管理するための分散システムである Apache Zookeeper などの使用を検討できます。それはより多くの作業とオーバーヘッドになりますが、おそらくあなたが望むように設定することができます.

于 2012-09-11T16:34:09.817 に答える