Can I use a single DynamoDB table to support these three use cases?

1
votes

I'm building a DynamoDB table that holds notification messages. Messages are directed from a given user (from_user) to another user (to_user). They're quite simple:

{ "to_user": "e17818ae-104e-11e3-a1d7-080027880ca6", "from_user": "e204ea36-104e-11e3-9b0b-080027880ca6", "notification_id": "e232f73c-104e-11e3-9b30-080027880ca6", "message": "Bob recommended a good read.", "type": "recommended", "isbn": "1844134016" }

These are the Hash/Range keys defined on the table:

HashKey: to_user, RangeKey: notification_id

Case 1: Users regularly phone home to ask for any available notifications.

With these keys, it's easy to fetch the notifications awaiting a given user:

notifications.query(to_user="e17818ae-104e-11e3-a1d7-080027880ca6")

Case 2: Once a user has seen a message, they will explicitly acknowledge it and it will be deleted. This is similarly simple to accomplish with the given Hash/Range keys:

notifications.delete(to_user="e17818ae-104e-11e3-a1d7-080027880ca6", notification_id="e232f73c-104e-11e3-9b30-080027880ca6")

Case 3: It may sometimes be necessary to delete items in this table identified by keys other than the to_user and notification_id. For example, user Bob decides to un-recommnend a book and we would like to pull notifications with from_user=Bob, action=recommended and isbn=isbnval.

I know this can't be done with the Hash/Range keys I've chosen. Local secondary indexes also seem unhelpful here since I don't want to work within the table's chosen HashKey.

So am I stuck doing a full Scan? I can imagine creating a second table to map from_user+action+isbn back to items in the original table but that means I have to manage that additional complexity... and it seems like this hand-rolled index could get out of sync easily.

Any insights would be appreciated. I'm new to DynamoDB and trying to understand how typical data models map to it. Thanks.

1
nosqlamazon-dynamodb

1 Answers

1
votes

Your analysis is correct. For case 3 and this schema, you must do a table scan .

There are a number of options which you've identified, but all of them will add a layer of complexity to your application.

  1. Use a second table as you state. You are effectively creating your own global index and must manage that complexity yourself. This grows in complexity as you require more indices.

  2. Perform a full table scan. Look at DynamoDB's scan segmenting for a method of distributing the scan across multiple worker nodes. Depending on your latency requirements(is it ok if the recommendations don't go away until the next scan?) you may be able to combine this and other future background tasks into a constant background process. This is also simpler than 1.

Both of these seem to be fairly common models.