dynamoDBを使用する場合-UseCases

Question

私は、Amazon DynamoDBに最適な最適なユースケースを理解しようとしました。私はブログのほとんどをGoogleで検索

はDyanmoDbだけ大量のデータ（BigData）のために使用される予定だという。

私はリレーショナルDBの背景を持っています。 NoSQL DBは私にとっては新しいものです。これを通常のリレーショナルDBの知識に関連づけようとしたところです。

DynamoDBのに関連する概念のほとんどは、パーティション・キー/ソートキーとスキーマレステーブルを作成することです。そして、キーに基づいてそれらを照会するようにしてください。また、照会をより簡単かつ簡単にするストアード・プロシージャーの概念はありません。

私たちは、このような複雑なクエリを実行し、このような膨大なデータの管理と、データを取得するために、毎回、ストアドプロシージャせずに正しいアプローチでしょうか？

注：私は多分概念の間違った理解を持っていました。だから、誰も事前にここに私の考え

感謝をクリアしてください
ジェイ要するに

Answer 1

は、DynamoDBのようなシステムは、大規模なデータセットをサポートするように設計されており、高い書き込み（単一のサーバーに合うように大きすぎる）/読み込みスループット垂直方向のスケーリングとは対照的に、水平にスケーリングすることによって、これは歴史的にリレーショナルデータベースのより一般的なアプローチです。水平方向のスケーラビリティーをサポートする

メインアプローチは、パーティションデータ、すなわちデータセットは複数の部分に分割し、複数のサーバに分散されることです。これにより、より多くのストレージとより多くのIOPSを使用できるようになり、より大きなデータセットと高い読み取り/書き込みスループットが可能になります。

データを複数の物理サーバに分散されるようしかし、データ・パーティショニングは、それが困難など参加するなど複雑なクエリをサポートすることができます。ストアドプロシージャに関しては、同じ理由でサポートされていません。つまり、ストアドプロシージャの背後にある考え方は、データの局所性です。つまり、ネットワーク操作なしでデータの近くのサーバーで実行されます。 （少なくともストアドプロシージャの形式で）。

したがって、このようなシステムからデータを照会する最も効率的な方法は、レコードキーによるものです。データパーティショニングはキーに基づいているため、特定のキーに対してレコードが物理的にどこに存在するかを簡単に特定できます。こうしたシステムの多くはセカンダリインデックスもサポートしていますが、通常は何らかの方法で制限されているか、高価であり、複雑なソフトウェアソリューションの要件を満たすには不十分です。非常に一般的なアプローチは、レコードの一部を複雑なクエリで実行してレコードキーを見つけ出し、そのレコードを読み込むための補完的なインデックス/クエリソリューション（ElasticsearchとSolrに基づいたソリューションを見てきました）です。 。