私はリレーショナルデータベースのバックグラウンドを持っており、AmazonのDynamoDBを使おうとしています。
ハッシュ キー「DataID」と範囲「CreatedAt」を持つテーブルがあり、その中に多数の項目があります。
特定の日付以降に作成され、日付順に並べ替えられたすべてのアイテムを取得しようとしていますが、これはリレーショナル データベースでは非常に簡単です。
DynamoDB で私が見つけた最も近いものは、クエリと、フィルターより大きい範囲キーを使用することです。唯一の問題は、クエリを実行するにはハッシュ キーが必要であり、これが目的に反することです。
では、何が間違っているのでしょうか? テーブル スキーマが間違っているのでしょうか。ハッシュ キーは一意であるべきではないのでしょうか。それとも、クエリを実行する別の方法があるのでしょうか。
ベストアンサー1
現在のテーブル構造を考えると、これは現時点では DynamoDB では不可能です。大きな課題は、テーブル (パーティション) のハッシュ キーを個別のテーブルの作成として扱う必要があることを理解することです。ある意味では、これは非常に強力です (パーティション キーを各ユーザーや顧客などに新しいテーブルを作成するものと考えてください)。
クエリは単一のパーティションでのみ実行できます。これで話は終わりです。つまり、日付でクエリを実行する場合 (エポックからのミリ秒を使用する)、単一のクエリで取得するすべての項目に同じハッシュ (パーティション キー) が必要です。
この点については注意が必要です。scan探している基準によってはまったく問題ありませんが、テーブル内のすべての行を調べて、その行にパラメータに一致する日付があるかどうかを確認することになります。これは非常にコストがかかります。特に、イベントを日付別に保存するビジネスを行っている場合 (つまり、行が多数ある場合) はなおさらです。
問題を解決するために、すべてのデータを 1 つのパーティションにまとめたくなるかもしれません。確かにそれは可能ですが、各パーティションには容量に関する独自の最大制限があるため、スループットは著しく低下します。テーブルがより高い制限またはより高いプロビジョニングされた容量をサポートしている場合でも、個々のパーティションは常にパーティション制限に制限されます。
最善の方法は、データを保存するために作成するより便利なパーティションを決定することです。
本当にすべての行を確認する必要がありますか、それとも特定のユーザーの行のみを確認する必要がありますか?
まずリストを月ごとに絞り込み、複数のクエリ (各月ごとに 1 つ) を実行しても問題ありませんか? または年ごとに実行しても問題ありませんか?
時系列分析を行う場合、いくつかのオプションがあります。パーティション キーを計算済みのものに変更して
PUT簡単にするqueryか、追加のみのログ記録に適した Kinesis などの別の AWS 製品を使用します。