0

최근에 일부 소셜 그래프 정보를 데이터베이스에 저장하려고하고 사용자가 소셜 그래프가있는 서버 쪽에서 발생하는 자동 "매핑"으로 새로운 소셜 노드를 발견합니다.AWS NoSQL 또는 AWS RDS, 소셜 그래프를 저장하는 좋은 방법은 무엇입니까?

배경 : 새 클라이언트가 방문 할 때마다 나는 다른 소스의 기존 소셜 노드를 저장합니다. 좋은 예는 Facebook입니다. 그래서 페이스 북 친구 목록과 그 고객의 페이스 북 ID를 가지고 데이터베이스에 그것들을 저장합니다. 그런 다음 서버는 클라이언트의 친구 목록에있는 각 항목을 기존 클라이언트와 일치 시키려고 시도합니다. 일치하는 것이 있으면이 클라이언트가 내 서비스를 사용하는 친구가 있음을 의미합니다. 그런 다음 일치하는 목록을 반환하고 가장자리의 다른 쪽에서 일치를 표시합니다. 다음 번에 고객의 친구가 돌아 오면 알림을 받게됩니다.

장애 : 내 문제는이 메커니즘 페이스 북 친구의 전체 목록은 '내 예제에서이 클라이언트이며, 소셜 그래프'는 고객의 전체 목록을 저장하기 위해 서버를 필요로한다는 것이다. 이 소셜 그래프는 임의로 커질 수 있기 때문에 하나의 항목으로 저장할 수는 없지만 클라이언트 ID와 친구 ID가있는 여러 항목이나 행에 걸쳐 표시 할 수는 있습니다. 이 방법으로 저장하면 키가 꽤 고르지 않게 분산되어 DynamoDB를 사용할 수 없습니다. 그러나 빠른 액세스 이점을 얻기 위해 일부 AWS NoSQL 서비스에이를 저장할 수있는 가능성을 모색하고 싶습니다.

AWS NoSQL 서버에 이러한 데이터를 저장할 수있는 좋은 방법이 있습니까? 아니면 RDS에 넣을 수 있지만 너무 많은 효율성을 잃지 않기 위해 할 수있는 최적화는 무엇입니까?

답변

2

실제로 DynamoDB는 사용 사례에 따라 매우 잘 작동 할 수 있습니다 ... DynamoDB는 다중 값 필드를 지원하며 최대 레코드 크기는 64k입니다.

'clientId'를 해시 키로 사용하고 'friendId'를 다중 값 필드로 사용하여 두 개의 열로 된 '친구'테이블을 만듭니다.

사용자의 전체 친구 목록을 저장할 때 하나의 레코드 만 필요하다는 것을 의미합니다 (GUID를 'friendId'로 가정하면 최대 약 4,000 명의 친구). 필요한 경우 4,000 명 이상의 친구가있는 사용자에게 여러 레코드를 사용할 수 있습니다.

관련 문제