Structuring DynamoDB tables vs traditional relational model - database

Question

I'm trying to wrap my head around DynamoDB's scans and queries, and how I should structure my tables.
Let's say I have buckets and marbles, and each bucket can contain many marbles. In a traditional relational database, I might set that up like this:
Buckets
id name
---------------
B1 Blue Bucket
B2 Red Bucket
Marbles
id name bucketId lots more fields...
------------------------------------------------
M1 Deep Swirls B1
M2 Fire Red B1
M3 Obsidian B2
As I understand it, if I structured my data this way in DynamoDB, it could be costly for RCUs because I'd have to do scans. If I wanted to get all the marbles in bucket B1, I'd have to do a scan of Marbles where bucketId = B1, which grabs the full list of marbles and then removes the ones that don't match (if I understand the inner workings of DynamoDB correctly).
This doesn't sound very performant or cost-effective. How should I structure this data?
IMPORTANT NOTE: Marbles should be able to exist on their own, i.e. part of no bucket. (bucketId = null)

Answer 1

You will want two tables to track this. bucket for the bucket and marble for the marble. A bucket will contain a list of marbles with some basic information (name, color, etc...) that you would use for displaying a quick list of the collection. Make sure to include the id of the marble. Then on the actual marble representation, put all of the information for the marble, plus a bucket object that will link back to it's assigned bucket. It would look something like this:
Marble
{
"id": 1,
"name": "Deep Swirls",
"color": "Red",
"complexProp": {
...
},
"bucket": {
"name": "Blue Bucket",
"id": 1
"
}
Bucket
{
"id": 1,
"name": "Blue Bucket",
"marbles": [
{
"id": 1,
"name": "Deep Swirls",
"color": "Red"
},
{
"id": 2,
"name": "Fire Red",
"color": "Red"
}
]
}
The downside to this approach is that you will need to update the marble in two places if anything changes (but if a marble changed color that would be rather impressive) if the changing data is in both places. You will also need to change data in two places if you change what bucket it is in. You can omit the bucket property on the marble representation if you don't care about quickly discovering which bucket a given marble is in.