自然キーのないログタイプのデータがあります。Amazon dynamodb では、テーブルの主キーにハッシュ属性が必要なので、uuid を使用する予定です。問題は、クエリを実行するときにハッシュ値を修正する必要があるようですが、もちろんすべてのログをクエリしたいので、単一の uuid を指定できないことです。この dynamodb クエリ要件を誤解していますか?
質問する
871 次
2 に答える
0
要件を誤解しないでください。
全テーブル スキャンを回避する唯一の方法は、特定の HashKey に対してクエリを実行することです。
どのようにデータをクエリしますか? ハッシュキーとして日付 (時間単位で可能) を使用し、UUID にローカル セカンダリ インデックスを作成することはおそらく理にかなっていますか?
于 2013-06-09T10:08:07.987 に答える
0
パフォーマンスとスループットのプロビジョニングを最適化したい場合はHash Key、クエリで を使用し、必要に応じてレコードを絞り込むフィルター式を使用する方法を見つけることをお勧めします(where a < latitude < b and c < longitude < d)。
詳細については、条件式による条件の指定を参照してください。
Hash Keyクエリで a を使用できず、 a を使用するScan必要がある場合は、時間の経過とともにデータをクエリする必要があると述べたConditional Expressionように、提案された時系列データのベスト プラクティスに従って、日付または時刻でテーブルをセグメント化することをお勧めします。
すべてのアイテムを 1 つのテーブルに格納する代わりに、複数のテーブルを使用してこれらのアイテムを格納できます。たとえば、月次または週次のデータを格納するテーブルを作成できます。データ アクセス レートが高い最新の月または週のデータを格納するテーブルについては、より高いスループットを要求し、古いデータを格納するテーブルについては、スループットをダイヤルダウンしてリソースを節約できます。
「ホット」アイテムをスループット設定の高いテーブルに格納し、「コールド」アイテムをスループット設定の低い別のテーブルに格納することで、リソースを節約できます。テーブルを削除するだけで、古いアイテムを削除できます。オプションで、これらのテーブルを Amazon Simple Storage Service (Amazon S3) などの他のストレージ オプションにバックアップできます。テーブル全体を削除すると、項目を 1 つずつ削除するよりもはるかに効率的です。これにより、書き込み操作と同じ数の削除操作を行うため、書き込みスループットが本質的に 2 倍になります。
于 2015-04-26T20:17:17.777 に答える