Best modeling tips in DynamoDB in User/Friend Tables

0
votes

In mysql a User and Friend Table will somewhat look like these

  • User Table
  • id
  • name
  • phone
  • status [enabled/disabled]

===============================================

  • Friend Table
  • user_id
  • another_user_id
  • status [if friend or not]

===============================================

but in DynamoDb

I have been troubled about these two ways either

Approach 1.

  • User Table
  • id
  • name
  • phone
  • friends -> attributes

OR

Approach 2.

  • User Table
  • id
  • name
  • phone

===============================================

  • Friend Table
  • user_id
  • another_userid

===============================================

Im currently using the Approach 2. question is whats the best way to model tables in cost effective manner , latency and performance?.

PS: I emailed their support about these problems for me but still has no reply from them so someone should already had gone through these problems.

I hope I iterated the question carefully to be understandable.

EDITED: @chen

Q: Do you often query a user's friend list?

A: yes I will query every users-friends-list that will use my software when a user logs in.

Q: Do you wish to know fast how many friends does a user have?

A: No, no need as long as i can get who the users friends are then its all good.

Q: How many friends do you think a user will have?

A: unlimited.

Q: How many users will the system have?

A: unlimited too.

thanks for giving the time.

thanks

2
mysqlamazon-dynamodbnosql
Hi David, I am also stuck with the problem you faced. My question is since it seems like you went with approach one, how did you handle updates to this attribute? Since two items need to be updated (for user1 and user2), how did you handle the transactional part of this as to avoid problems if there is a crash and only one user's friends attribute got updated, but the others did not? - user2924127

2 Answers

2
votes

David, you are running into a typical NoSQL problem.

When designing a relational database, you model the data as it fits the world, and also try to break the data into tables.

In DynamoDB (and other NoSQL) the real model is derived from the questions needing answers.

Do you often query a user's friend list? Do you wish to know fast how many friends does a user have? How many friends do you think a user will have? How many users will the system have?

These questions will help you decide between approach #1 and #2. If you comment with answers to these questions, I will be able to give you my thoughts on the model.

Regardless, if you really want to drop SQL, you might want to look at graph databases.

0
votes

If you must use DynamoDB, then just keep references in the same table (approach 1). Have you already taken a decision on which DB to use? Couple of Reasons: Some other NoSQL DBs have a vibrant community and great documentation.

GraphDB best seems to suit your problem above, but you are better aware of your systems' big picture.