0

最近、いくつかのソーシャル グラフ情報をデータベースに保存したいと考えています。ユーザーは、ソーシャル グラフを持つサーバー側で発生する自動「マッピング」によって新しいソーシャル ノードを発見します。

背景: 新しいクライアントが訪問するたびに、他のソースから既存のソーシャル ノードを保存します。その 1 つの例が Facebook です。そのため、Facebook の友達のリストとそのクライアントの Facebook ID があり、それらをデータベースに保存しています。次にサーバーは、クライアントのフレンド リスト内の各項目を既存のクライアントと照合しようとします。一致する場合、このクライアントには私のサービスを使用している友人がいます。次に、サーバーは一致したリストを返し、エッジの反対側で一致をマークします。次にクライアントの友達が戻ってきたときに、マッチングが完了したという通知も受け取ります。

障害: 私の問題は、このメカニズムではサーバーがクライアントのソーシャル グラフの完全なリストを格納する必要があることです。私の例では、これはクライアントの Facebook の友人の完全なリストです。このソーシャル グラフは任意に大きくなる可能性があるため、1 つのアイテムに格納することはできませんが、クライアント ID とフレンド ID のペアを使用して、複数のアイテムまたは行にまたがります。この方法で保存すると、キーがかなり不均一に分散される可能性があり、DynamoDB を使用できなくなります。ただし、高速アクセスの利点を得るために、一部の AWS NoSQL サービスに保存する可能性を探りたいと考えています。

これらのデータを AWS NoSQL サーバーに保存する良い方法はありますか? または、効率をあまり落とさずに RDS に入れるためにできる最適化は何ですか?

4

1 に答える 1

2

実際、DynamoDBはユースケースに非常に適している可能性があります... DynamoDBは複数値フィールドをサポートし、最大レコードサイズは64kです。

したがって、ハッシュキーとして「clientId」を使用し、複数値フィールドとして「friendId」を使用して、2列の「friends」テーブルを作成します。

つまり、ユーザーの完全な友達リストを保存するために必要なレコードは1つだけです(GUIDを「friendId」とすると最大約4,000人の友達)。また、必要に応じて、4,000人を超える友達がいるユーザーに複数のレコードを使用できます...

于 2012-06-05T18:47:00.387 に答える