3

予想される大規模なデータセット用に DynamoDB を検討しています。私は SQL に強いバックグラウンドを持っているので、No-SQL の考え方は私にとって新しいものです。

問題と設計がありますが、行き止まりのように見えます。
ドキュメントには、パフォーマンスを向上させるためにハッシュキーが広く配布されていることを確認するように記載されていますが、それは理にかなっています。

ユーザーのさまざまなデータポイント/アクションを記録します。ハッシュキーがユーザーIDであるべきであり、私の範囲キーが実行されるアクションであることは私には理にかなっています。

ここで、ユーザー #1 が実行するすべてのアクションが必要な場合は、簡単にクエリを実行できます。
しかし、アクション X を実行したすべての USERS が必要な場合は、テーブル スキャンなしでは実行できません。クエリのドキュメントから:

クエリ操作は、テーブルの主キーを使用してテーブルからアイテムに直接アクセスするか、インデックス キーを使用してインデックスからアイテムに直接アクセスします。特定のハッシュ キー値を指定する必要があります。

そのため、遅く、多くの容量ユニットを消費するtable scanを実行しない限り、特定のユーザーからデータを取得することに制限されているように見えます。

私の質問は、最終的にはデザインの問題だと思います。No-SQLに関しては、何かが足りないのではないでしょうか? 私のハッシュキーは別のものであるべきですか？それとも、私の要件が No-SQL (より具体的には DynamoDB) に適合しないということですか?

ハッシュキーは DynamoDB との一種のグループ化であるかのようです。予定しているアクションに合わせてハッシュ キーを変更することを検討しましたが、キーを広く配布する予定はありません...

4

3 に答える 3

1

単一のテーブルを取得するため、グローバルセカンダリインデックスオプションの方が優れていると思います。

2 つのテーブルを作成すると冗長性が生まれ、任意の 1 つのテーブルで CUD (作成、更新、削除) 操作を実行するときに一貫性を維持するための追加作業が発生します。

于 2013-05-28T01:00:24.100 に答える
1

Global Secondary Index (GSI)を作成する必要があります。これにより、元のキーとは異なるハッシュ キーと範囲キーの 2 番目のペアが作成されます。次に、パラメーターにインデックス名も含めることで、同じテーブルをクエリできます。

JS での例:

var table = tablename;
var index = actionId-username-gsi;
var action = actionId;
var params = {
    TableName : table,
    IndexName : index,
    KeyConditionExpression : 'actionId = :v_actionId',
    ExpressionAttributeValues : {
        ':v_actionId': { N : action }
    },
    ProjectionExpression : 'actionId, username'
};
ddb.query(params, err) {
    if(err) {
        // Oh well
    } else {
        // Do something
    }
};

これにより、actionId-username-gsiインデックスが照会され、提供された値で actionId ハッシュが検索されます。ProjectionExpressionを使用すると、アイテムごとに指定された属性の値のみが返されるため、それが懸念される場合はスループットが低下します。これがあなたの質問に答えるのに役立つことを願っています.

于 2016-01-13T17:49:52.617 に答える