I’m trying to better understand how to work with D...
# sst
c
I’m trying to better understand how to work with DyanmoDB. One thing that’s confusing is the use of
primaryIndex
in SST’s Table construct. Is this value a 1:1 with the Primary Key concept from DDB’s documentation - or does it encapsulate something more? And, if it is the same, is the reason for the different name in SST to normalize it with ‘Secondary Index’ or something else?
t
I think the nuance is DynamoDB allows you to define
primaryIndexes
- these are often used to define a Primary Key
CDK calls it primary indexes as well
c
Between Primary Key, Partition Key, and Sort Key it feels like an Oprah taping
t
lol
Yeah fwiw I just read the dynamodb book by alex debrie and skipped the docs
c
So Primary Index can = Primary Key but isn’t the necessarily the Primary Key?
t
yeah but 99% of the time you're using a primady index to define a primary key
also this video:

https://www.youtube.com/watch?v=Xn12QSNa4RE&t=1382s

also people interchange partiton key with the term primary key
c
Ah, thanks. I think I saved a ref to Alex’s book and hadn’t recalled to go back and check it out
also people interchange partiton key with the term primary key
and this is why we can’t have nice things
Thanks for the help Dax
d
Primary Key aka Partition Key Sort Key aka Range Key
c
Haha, hadn’t even run into the Range Key yet. This may drive me to drink
d
Note that “primary index” isn’t a thing in DynamoDB, it’s just referred to as the table. I suspect that SST didn’t want to reuse the word Table because it would be confusing, hence “Primary Index”.
c
Thanks guys, looks like I still have some homework and untangling to do
d
You can set the PK/SK on the table itself (SST refers to it at the “primary index”). You can then add global secondary indexes (GSIs) and local secondary indexes on top of it, which in the most basic sense are like copies of the table, but with a different index applied.
I found it all super confusing at first, but this video really helped me, he explains it really well as you need to think of dynamo in a completely different way to traditional databases -

https://www.youtube.com/watch?v=BnDKD_Zv0og

Plus all the questions the attendees ask at the end were basically the exact questions in my head haha
c
Fantastic, thanks a ton for these
r
Yeah, agree with Dax, go read Alex DeBrie's The DynamoDB Book it's real world practical
r
@Clayton DynamoDB has been responsible for a fair bit of my alcohol intake :). It's just so different. Totally worth learning and getting an appreciation for. Doing it again, I would most definitely take the advice of these wise sages.
m
all three of the linked resources are great - once you grok dynamodb single-table design it’s very hard to go back to the RDMS world with joins and the bigger lift to get the infra set up
oh, one other thing - the experts don’t always agree on their best practices either. Rick and Alex are often at odds - it’s ok for you to choose your own way after trying them out. Rick likes a “type” attribute that tells you what the item is and alex does not is an example
one likes GSI1PK and the other likes something else
r
A couple of other things, the OneTable package makes interacting with a one table design much easier. It allows you to define a schema and autopopulate your PK and SK based on properties in that schema. Another thing, you don't have to go totally one table for everything. If there are unrelated entities in your data structure, these can happily live in separate tables which can afford you more flexibility if you need to make changes later.
This is worth a read as a summary of approaches and some recommendations based on experience
m
Second @Ross Coundon point about about multiple tables. Single table design applies to well.... a single table, but it's definitely ok to have multiple tables that take advantage of single table design and or other methods. Aggregate tables, key value store etc.
r
Indeed @Mike McCall, we love us some multiple, single table design 😕 😄
c
Fantastic, thanks again. I really appreciate all of the help and resources. Can’t say that I care much for Slack, but I definitely can’t get enough of this one 😅
m
Slack is life!
k
I can’t say enough how much Alex’s book help me get my head around DynamoDB https://www.dynamodbbook.com
I’ve been a bit resistant to the idea of Dynamodb, even though I’ve had multiple NOSQL projects with Mongo… that said I spent four days reading Alex’s book and other dynamo references, and think I’m there. Particularly around the shift the access patterns, root aggregates and optimal schemas for those patterns in dynamo… it totally different, but I can see how that the query patterns mapped to the way data will be stored is more scalable and will def be faster… it does make the brain hurt though ;)
It all feels like part of this serverless adventure
Here’s some more that I’ve been reading: https://www.jeremydaly.com/how-to-switch-from-rdbms-to-dynamodb-in-20-easy-steps read and watch all links
m
100% agree. If it weren't for that book I probably wouldn't be using dynamodb.