2

数テラバイトの住所データがあり、これを DynamoDB NoSQL データベースに保存する可能性を調査しています。私は一般的に DynamoDB と NoSQL についてかなりの量を読んできましたが、長年の MS SQL から来ており、NoSQL の概念のいくつかに苦労しています。

この時点での私の最大の疑問は、データをクエリするさまざまな方法に対応できるようにテーブル構造をセットアップする方法です。たとえば、通常の SQL では、次のようなクエリが期待されます。

WHERE Address LIKE '%maple st%' AND ZipCode = 12345

WHERE Address LIKE '%poplar ln%' AND City = 'Los Angeles' AND St​​ate = 'CA'

WHERE OwnerName LIKE '%smith%' AND CountyFIPS = '00239'

これらはほんの一例です。実際のクエリは、これらのさまざまなフィールドの任意の組み合わせにすることができます。

インデックスがどのように見えるべきか、またはテーブル (または複数のテーブル) がどのように構造化されるべきかが明確ではありません。それがどのように機能するかを理解し始めてくれる人はいますか?

4

2 に答える 2

0

投稿は比較的古いですが、回答を提供しようとします（将来、同様の問題を抱えている人に役立つかもしれません）。

DynamoDB は、あなたが説明した方法で使用することを意図したものではありません。その強みは、キーと値のペアの高速な (実際には喫煙が速い) ルックアップにあります。IP アドレスに関連付けられた情報を非常に迅速に検索したい場合に IP アドレスの例を挙げると、HashKey を IP アドレスの文字列にして、これを使用して検索を行うことが簡単にできます。

dynamoDb でクエリ (またはスキャン) を実行したい場合は、複雑になります。ここでそれらについて読むことができます: DynamDB でのクエリとスキャン

要点は、スキャン/クエリは、HaskKey または HaskKey+RangeKey コンボ (レンジ キーは基本的に複合キー) で実行されない場合、非常にコストがかかるということです。

つまり、DynamoDb が正しい方法であるかどうかはわかりません。高速検索機能を使用するには、Luceneのようなものを使用することを検討します。インデックスを賢く構成すると、その動作速度に驚かれることでしょう。

お役に立てれば。

編集: Amazon がセカンダリ インデックスのサポートを追加したようです: ここを参照してください

于 2013-04-12T15:26:43.597 に答える
0

DynamoDB は、質問の作成者が説明する方法で利用されるように構築されました。このリンクを参照してください。AWS のドキュメントでは、このようなセカンダリ インデックスの作成について説明されています。

[country]#[region]#[state]#[county]#[city]#[neighborhood]

パーティション キーは、検索対象に基づいて、このようなものになることもあります。

DynamoDB では、テーブルを作成する前に結合を作成します。これは、データを検索し、インデックスを作成し、それらを使用してデータをクエリする方法をすべて検討する必要があることを意味します。

AWS は、チームがこれを行うのを支援するためにAWS noSQL WorkBenchを作成しました。この記事の執筆時点で、そのアプリケーションにはいくつかの UI バグがあります。バグの詳細については、 LINKを参照してください。

あなたが言及したいくつかのクエリを確認するために、そのクエリを作成するためのインデックスを作成できるいくつかの可能性を共有します。

注: noSQL は場合によっては非正規化されたデータを意味しますが、必ずしもそうとは限りません。

dynamoDB が実際のサーバーを分割してスケーリングできるようにキーを形成する方法には制限があります。詳細については、パーティション キーを参照してください。

dynamoDB の魔法は、テーブルが作成されて本番環境で使用された後に新しいクエリも処理できる、よく考えられたモデルです。これを行う方法を説明する投稿やビデオがオンラインでたくさんあります。

これは、リック・フーリハンのリンクがあるものです。Rick Houlihan は DynamoDB のプリンシパル デザイナーです。

試行しているクエリを作成するには、主に初期パーティション キーとセカンダリ キーの複数のキーを作成します。Rick は、それらを PK や SK のように一般的なものにしておくことを推奨しています。

次に、多くの一意性を備えた PK を形成してみてください。たとえば、郵便番号 PK のパーティション キー: "12345" には、パーティション キー制限の 10GB クォータを超える可能性がある大量のデータが含まれる可能性があります。

例 1: WHERE アドレス LIKE '%maple st%' AND ZipCode = 12345

たとえば、「12345:maple」という PK のパーティション キーを作成すると、「12345:maple」という PK を呼び出すだけで、その郵便番号のすべてのデータと、maple の通りが取得されます。多くの異なる PK があり、それが dynamoDB の得意とするところです: 水平方向にスケーリングします。

例 2: WHERE Address LIKE '%poplar ln%' AND City = 'Los Angeles' AND St​​ate = 'CA'

例 2 では、セカンダリ インデックスを使用して、PK: "12345:poplar" SK: "losangeles:ca:other:info:that:helps" など、より具体的な別の方法を追加できます。

例 3: WHERE OwnerName LIKE '%smith%' AND CountyFIPS = '00239'

例 3 には通りの名前がありません。データをクエリするには、通りの名前を知る必要がありますが、検索に含まれていない可能性があります。これは、基本的なクエリ パターンを完全に理解し、クエリ時に簡単にわかるように PK を形成する必要があります。通りの名前を持つことはおそらく最適ではないでしょう。それはすべて、必要なクエリによって異なります。

この最後の例では、いくつかのグローバル セカンダリ インデックスを追加する方が適切な場合があります。これは、CountyFIPS のようなデータ属性 (列) にマップする新しいプライマリ キーとセカンダリ キーを作成することを意味します。

于 2021-05-21T01:07:54.473 に答える