DynamoDB テーブルに次のデータがあります。
これが私のコードです:
const userStatusParams = {
TableName: process.env.USERSTATUS_TABLE,
KeyConditionExpression: "loggedIn = :loggedIn",
ExpressionAttributeValues: {
":loggedIn": true
}
};
var usersResult;
try {
usersResult = await dynamoDbLib.call("query", userStatusParams);
console.log(usersResult);
}catch (e) {
console.log("Error occurred querying for users belong to group.");
console.log(e);
}
Amazon は次のエラーを返します:
{ ValidationException: Query condition missed key schema element: userId
at Request.extractError ...
loggedIn == true であるすべてのレコードを返すにはどうすればよいでしょうか?
私のデータベースは現在、serverless.yml 構成によって次のように構造化されています。
phoneNumberTable: #This table is used to track phone numbers used in the system.
Type: AWS::DynamoDB::Table
Properties:
TableName: ${self:custom.phoneNumberTable}
AttributeDefinitions: #UserID in this case will be created once and constantly updated as it changes with status regarding the user.
- AttributeName: phoneNumber
AttributeType: S
KeySchema:
- AttributeName: phoneNumber
KeyType: HASH
ProvisionedThroughput:
ReadCapacityUnits: ${self:custom.dynamoDbCapacityUnits.${self:custom.pstage}}
WriteCapacityUnits: ${self:custom.dynamoDbCapacityUnits.${self:custom.pstage}}
他の回答を参考にして少し調べてみましたが、自分の状況はわかりませんでした。他の回答ではソートキーがありましたが、ここではソートキーを使用しません。
ベストアンサー1
行う場合queryは、主キーを渡す必要がありますuserId。これは、あなたの場合は です。 を持っていない場合primaryKey、すべてのフィールドが必要な場合は、次のようにlogged in = trueします。scanfilterExpression
const userStatusParams = {
TableName: process.env.USERSTATUS_TABLE,
FilterExpression: 'loggedIn = :loggedIn',
ExpressionAttributeValues: {
":loggedIn": true
}
};
var usersResult;
try {
// Do scan
usersResult = await dynamoDbLib.call("scan", userStatusParams);
console.log(usersResult);
}catch (e) {
console.log("Error occurred querying for users belong to group.");
console.log(e);
}
アップデート：操作の効率が悪いためscan、この問題を解決するもう1つの方法はGSI、主キーを持つを作成することですloggedIn。しかし、ここでの問題は、 を持つフィールドを主キーにできないことです。booleanデータ・タイプ。である必要がありますnumber, string, binary。したがって、 を作成するには、 の代わりに、gsi受け入れられるデータ型を フィールドに格納する必要があります。loggedInboolean
1000件のレコードがあるテーブルではパフォーマンスにどの程度影響するかはわかりませんが、良い点はgsi、後で既存のテーブルでも将来、パフォーマンスへの影響が判明した場合。また、gsiテーブルに作成できる の数は に制限されています5。したがって、gsi賢く利用してください。