2017-12-13 8 views
0

これは私の基本的なデータ構造(またはとにかく関連する部分)です。私は、ファイルのデータを保持し、ファイルのIDを持っているファイルテーブルがあります。私はまた、ファイルに定義された項目を保持する「定義」テーブルを持っています。定義には、ソースファイルに定義を結び付けるために、ID(プライマリキー)とファイルIDを参照する 'SourceFile'というフィールドもあります。DynamoDBタイトなループまたはスキャンでクエリを実行しますか?

ほとんどの場合、私はそのIDで定義を取得し、オプションであとでファイルを取得してうまく動作したいだけです。しかし、場合によっては、一連のファイルのすべての定義を取得する必要があります。私はスキャンでこれを行うことができますが、それは遅いです、そして、私はテーブルが成長するにつれてより遅くなることを知っています、そして、それは推奨されません。しかし、私はどのようにクエリでこれを行うか分からない。

SourceFileフィールドを主キーとして使用するGSIを作成し、これを使用して照会することができます。これは答えのように聞こえるかもしれませんが、わかりません。問題は、一部のライブラリに5kまたは10kのファイルがあることです(まれにしかないかもしれません)。 GSIでは、クエリごとに1つのファイルIDに対してしか照会できないので、各ファイルに対して新しいクエリを投げなければならないので、DynamoDBで10Kのクエリを投げるのは非常に効率的だとは思いません...

タイトなループ(または複数のスレッド)を作成し、大量のクエリやテーブルをスキャンする方が良いでしょうか?これを行う別の方法は私が考えていないですか?

これは、それはそれはインスタントではないということ大丈夫ですが、私はそれが可能な限り効率的になりたいので、少し時間がかかると予想されるインデックス作成と解析プロセス中にある...

答えて

1

スキャンがありますデータベース内の大部分のデータを検索すると予想される場合は、最も効率的です。スキャン要求ごとに最大1MBを取得でき、使用可能な容量単位ごとに4KBを読み取ることができるため、プロビジョニングされた容量が十分であると仮定すると、1回の要求で数千のアイテムを取り出すことができます。

私が考えることのできる唯一の代替案は、より高いレベルでファイル&の定義を索引付けするのに役立つメタデータを追加することです(たとえば、ライブラリー名/ IDなど)。これで、ライブラリ名/ idにGSIを作成し、そのようにクエリできます。

何千ものクエリを実行することは、数十万または数十万のアイテムのオーダーに格納していると仮定すると、スキャンよりも効率が悪くなります。

+0

フィードバックありがとうございます。実際には大部分のデータではなく、特定の会社のデータの大半ですが、テーブルには多くの企業が存在します...他のメタデータに関する良い提案です。私は最初にライブラリについて考えなかったが、ライブラリIDをテーブルに入れてGSIを作成するのは難しくなかった。 – sfaust

関連する問題