Thread by @QuinnyPig

Given that:

A) there are no conferences at the moment so I'm getting rusty,
2) I haven't seen @houlihan_rick's reInvent talk yet, and
iii) I've never livetweeted a 400 level talk before, I will now attempt it while watching this video:

And we're right off to the races with this talk. No intro music cranked up to 11.

No giant wall of logos. Just @houlihan_rick getting right into it.

He has the grace to introduce himself fully, rather than "this is a 400 level DynamoDB talk, you'd better know who I am."

"Most of you have heard this already, but repeating things is important."

This is backed up by the repetition inherent to many of DynamoDB's own API calls.

Rick points out the inherently cyclical nature of various database technologies, pointedly snubbing Route 53. He mentioned "ledgered accounting" to give false hope to the Blockchain Enthusiasts.

We pause here for a quick bathroom break. Video @houlihan_rick is way more tolerant of the break request than Actual @houlihan_rick would be while giving the talk.

"EXCUSE ME! NO, I'M NOT A PROTESTOR, CAN YOU HANG ON FOR A COUPLE OF MINUTES WHILE I USE THE POTTY?! THANKS!"

We resume.

Rick discusses what it's like to encounter technology limits when workloads scale to Amazon size.

"Today we know how to understand relational technology. Tomorrow we will know how to model data in noSQL models." And Thursday we'll be using Route 53 hosted zones for everything.

Translating @houlihan_rick's subtext:

"If you have ad-hoc queries, every side of NoSQL is the sharp end."

Discusses the pain of scaling up @MongoDB shards. He's not at all wrong. One thing I'll grant DynamoDB, it's effectively hands-off from a management perspective as you scale.

"Find me another NoSQL database that can push 54 million TPS."

"Now that I've talked about the history of NoSQL at length, let's just breeze over what partition and sort keys are as well as attributes since that's the stuff everyone already knows." Video Rick gets less annoyed when you slow him down and make him repeat than Actual Rick.

Key takeaway: your access patterns define your data model.

Ergo you've gotta know your access patterns before you design your tables.

"The crux of design here is to design tables so that a single query can return the data I care about without having to talk to different tables relationally."

We pause @houlihan_rick momentarily because he just said something in passing that caused me to spit my tea across my keyboard. Time for a quick fact check...

Okay. What @houlihan_rick said was "there's a 100% SLA guarantee on GSI replication" but I can't find that 100% SLA cited anywhere in the formal @awscloud docs. It may be a design goal? Help?

Talking about scaling throughput. Nothing I've built has this concern; my stuff is all piddly in scale so far.

But I bet I can misarchitect it so that it scales DynamoDB nicely despite the low traffic levels!

"You're going to want to conceal a lot of this behind some API so your users don't have to think about any of this." OH MY GOD YES. Don't expose your implementation details to me!

Name-checks the CloudWatch feature (Contributor Insights) that shows hot keys.

Yay, I don't have to barter chunks of my soul to get these heatmaps from AWS Support anymore!

This is what it looks like when you haven't screwed up your access modeling:

Talking about DynamoDB's autoscaling. Which itself is... fraught. "The capacity you need, 20 minutes after you needed it" far too often.

"I'm not going to talk too much about pricing models." True. @houlihan_rick certainly doesn't pretend to be a Cloud Economist!

But I certainly pretend to know how noSQL works, since that professional courtesy doesn't apparently extend the other way...

"Uh, our APM is telling us we're seeing ludicrous query volumes, is it broken?" "Nope!" <-- a common occurrence.

"You get a 5 minute burst bucket rather than your database pulling a MongoDB and crashing into the sea."

(I kid. MongoDB is just fine for your production data. Not *MY* production data though--that stuff is important!)

Talking about ever-increasing complexity with traditional SQL models.

Meanwhile the O(1) time complexity is huge. It means that under load your database won't slam to a halt. Well, until you run out of money, anyway...

"If I swap the partition and sort keys as part of a secondary index, I can model SQL style joins and model many to many relationships."

I'd like to see DynamoDB items represented as YAML. #awswishlist

Closer--we're now representing it as Microsoft Excel!

"The fastest way to query DynamoDB is putting your non-indexed attributes as JSON objects." I--what?!

Architectural diagrams are always lies. In this one it shows Amazon ElasticSearch as if it could catch anything DynamoDB related that fell over...

"Given that none of you seem adequately impressed yet, here's a single table with nine distinct access patterns."

WHAT IS GOING ON

One day @houlihan_rick will go too far and AWS will punish him by forcing him to give an "Advanced Design Patterns in SimpleDB" talk.

"And this GSI gives you another nine access patterns..."

Meanwhile I'm here using six DynamoDB tables to build a single URL.

"And our third index just lets you use three access patterns."

My mind is spinning.

"With real data you may have to ETL the data into a new table structured differently."

Huh. This isn't a one-way door after all.

A plug for the now-GA noSQL Workbench for DynamoDB. It's pretty slick!

I think @houlihan_rick should give this same talk at reInvent again this year. If questioned about it, he should defend it as being the only authoritative talk on the subject, because there's...

no sequel.

The Database certification is now GA--and all certs can be proctored remotely until further notice.

And that's the talk!

And as an added trivia bonus for reading this far:
He almost certainly wouldn't remember, but back in 2018 before most folks had heard of me, @houlihan_rick and I were on a panel together in Australia.