3

私たちのプラットフォームのユーザーは、システムに大量のデータを保存しています。アプリケーションを介して接続すると、そのデータが転送され、サーバーに残る必要がなくなります。いつでも数百または数千のユーザーが接続し、ダウンロードを実行している可能性があります。

提案されたアーキテクチャは次のとおりです。

ユーザー管理、構成、およびデータ ダウンロードの統計は、SQL Server データベースで維持されますが、大規模なデータ セットには Redis または DynamoDB を使用します。

Redis または DynamoDB を選択する理由は、コスト (別の SQL Server インスタンスを実行するよりも安価) とパフォーマンスに基づいています。データ形式は、データマート (結合のないフラット テーブル) に似ています。

最初のクエリは単純です。日付範囲内のユーザー X のすべてのデータを取得し、オプションで削除します。

そのデータの特定のフィールドに対してフリーテキスト検索を追加したい場合があるため、 elasticsearchを使用することは、最初から使用するより良いオプションである可能性があります。

これを自動スケーリングにしたいのですが、このシナリオにどのデータベースを使用するのが最適かわかりません。

4

2 に答える 2

4

AWS ReInvent からのデータベース + 検索層に関するいくつかの優れた議論を次に示します。

https://youtu.be/K7o5OlRLtvU?t=1574

どのデータ ストアを使用すればよいですか?

于 2016-01-20T23:42:00.643 に答える
0

書き込み容量の自動スケーリングを提供しないため、Elastic-search だけを使用することはありません。実際、インデックスのシャード数を増やすことは簡単ではありません。次に、JSON 形式しか処理できないため、問題になる可能性があります。

Redis は非常に高速で、すべてが RAM で実行され、有効期間が制限されたキーを提供するため、興味深いものになる可能性があるため、良いアイデアになる可能性があります。残念ながら、データ サイズが Amazon インスタンスの RAM の容量を超える場合は、Redis データベースを分割する必要があります。また、Redis はそれをサポートしていません。アプリケーション コードで処理する必要があります。さらに、私の知る限り、Redis は複雑なクエリを処理しません。また、問題になる可能性があるRedisデータ構造にデータを保存する必要があります

DynamoDB は自動スケーリングを非常にうまく処理しますが、一方でキー/値データベースであるため、「日付範囲内のユーザー X のすべてのデータを取得する」などのクエリを作成することはできません。DynamoDB では、データを任意の形式で保存することもできます。

解決策は、データのサイズに応じて DynamoDB または Redis のいずれかを使用し、メタデータ (ユーザーと日付) のみでキーをインデックス化するために ElasticSearch を使用することです。そのように、インデックスは小さくなり、ElasticSearch が忙しすぎてインデックスを作成できなくなった場合でも、ユーザーのデータを保存する機能を維持できます。

于 2014-03-11T09:01:40.727 に答える