Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The DynamoDB Book: Data Modeling with NoSQL and DynamoDB

dynamodbbook.com

Post reply on HN
Print view View original

91–100 of 114 posts

Re: The DynamoDB Book: Data Modeling with NoSQL and DynamoDB

#91

Post by abd12 »

jeremyjh wrote: post #89
abd12 wrote: post #38

Earlier quoted context omitted.

My contention is that it's much easier to have an access pattern that won't scale in a relational database than in DynamoDB. DynamoDB basically removes all the things that can prevent you from scaling (JOINs, large aggregations, unbounded queries, fuzzy-search). This is underrated, but it's really helpful. So many times w/ a relational database, I've had to tweak queries or access patterns over time as response times…

So what is the cost of doing a bit of query tuning and de-norming every now and then compared to the development costs imposed by DynamoDB?

It depends!

For me, I like that 98% of DynamoDB work is frontloaded. I spend the time building the model but once it's done -- set it and forget it.

With RDBMS, it's like there's a hidden 5% tax that's lurking at all times. You have to spend time tuning querying, reshaping data, changing patterns, etc. It can add up to significant drag over time.

Different teams might think the costs are different for their application, or they may be fine with one pattern over the other. Fine with me! I just know which one I choose now :)

Re: The DynamoDB Book: Data Modeling with NoSQL and DynamoDB

#92

Post by scarface74 »

abd12 wrote: post #58
scarface74 wrote: post #56

Earlier quoted context omitted.

Workloads w/ serverless compute (aka Lambda) due to how well it fits with the connection model, provisioning model, etc. If you can use Aurora Serverless, the Data API makes sense for lambda. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...

True! I'm not a huge fan of Aurora Serverless and the Data API. The scaling for Aurora Serverless is slow enough that it's not really serverless, IMO. And the Data API adds a good bit of latency and has a non-standard request & response format, so it's hard to use with existing libraries. But it's definitely an option for those that want Lambda + RDBMS. The RDS Proxy is _hopefully_ a better option in this regard but…

We can’t use Aurora Serverless even in our non Prod environments because we have workflows that involving importing and exporting data to and from S3. But really, our Aurora servers in those environments are so small that most of our costs are storage.

Re: The DynamoDB Book: Data Modeling with NoSQL and DynamoDB

#93

Post by ryanmarsh »

arpinum wrote: post #24

I bought the book, I read the book, I've used DynamoDB for awhile. It didn't change my mind. DynamoDB makes tradeoffs in order to run at massive scale, but scale isn't a problem many people need solving when 2TB of RAM fits in a single box. Meanwhile I need to handle eventual consistency, an analytics pipeline, another database for fuzzy search, another geo lookup database, Lambda functions to do aggregations, and a…

Very disappointed to find the top comment is about DynamoDB and not Alex and his wonderful book. I suppose this is par for the course with HN. I hope nothing I create ever ends up posted here.

Re: The DynamoDB Book: Data Modeling with NoSQL and DynamoDB

#94

Post by dkobia »

abd12 wrote: post #3

Waves Author here. Happy to answer any questions folks have about the book, about DynamoDB, or about self-publishing. NoSQL modeling is waaay different than relational modeling. I think a lot of NoSQL advice out there is pretty bad, which results in people dismissing the technology altogether. I've been working with DynamoDB for a few years now, and there's no way I'll go back. The book has been available for about a…

Any chance for a Kindle friendly mobi?

Re: The DynamoDB Book: Data Modeling with NoSQL and DynamoDB

#95

Post by kulig »

zemo wrote: post #74
danenania wrote: post #21

DynamoDB is very compelling for performance, scalability, and low ops overhead, but I recommend thinking very carefully about the limited transaction support before going with it, as it’s likely to be a dealbreaker for many use cases, whether or not you realize that up front. I think most apps will need a transaction involving more than 25 rows at some point, and with dynamo your only option is to fire them off in gr…

> I think most apps will need a transaction involving more than 25 rows at some point I ... can't think of a single time I've ever needed this.

Youve never worked on a minimally complex enterprise application?

Re: The DynamoDB Book: Data Modeling with NoSQL and DynamoDB

#96

Post by dgemm »

DVassallo wrote: post #65
abd12 wrote: post #60

Earlier quoted context omitted.

Daniel, I'm a big fan of yours but disagree with this take :). It's definitely a database. The modeling principles are different, and you won't get some of the niceties you get with a RDBMS, but it still allows for flexible querying and more. S3 is not a database, but DynamoDB is :).

S3 and DDB are incredibly similar. Their fundamental operators are the same: key-value get/put and ordered list, and their consistency is roughly the same. What differentiates DDB and S3 the most is cost and performance. They're both highly-durable primitive data structures in the cloud, with a few extra features attached.

If you think of them as incredibly similar then you are likely not making very good use of them.

For example consistency is not "roughly the same" with DynamoDB supporting strongly consistent and atomic operations, and atomic update operations.

Re: The DynamoDB Book: Data Modeling with NoSQL and DynamoDB

#97

Post by Scarbutt »

abd12 wrote: post #3

Waves Author here. Happy to answer any questions folks have about the book, about DynamoDB, or about self-publishing. NoSQL modeling is waaay different than relational modeling. I think a lot of NoSQL advice out there is pretty bad, which results in people dismissing the technology altogether. I've been working with DynamoDB for a few years now, and there's no way I'll go back. The book has been available for about a…

and there's no way I'll go back.

err.. back to what?

Re: The DynamoDB Book: Data Modeling with NoSQL and DynamoDB

#99

Post by DVassallo »

dgemm wrote: post #96
DVassallo wrote: post #65

Earlier quoted context omitted.

S3 and DDB are incredibly similar. Their fundamental operators are the same: key-value get/put and ordered list, and their consistency is roughly the same. What differentiates DDB and S3 the most is cost and performance. They're both highly-durable primitive data structures in the cloud, with a few extra features attached.

If you think of them as incredibly similar then you are likely not making very good use of them. For example consistency is not "roughly the same" with DynamoDB supporting strongly consistent and atomic operations, and atomic update operations.

S3 is also immediately consistent unless you’re updating an existing object or listing objects.

I was one of the top users by volume of both products when I worked at AWS.

Re: The DynamoDB Book: Data Modeling with NoSQL and DynamoDB

#100

Post by ignoramous »

abd12 wrote: post #47
cactus2093 wrote: post #27

Earlier quoted context omitted.

Interesting, idk that I've ever needed a transaction with more than 25 rows. But I agree in general about the limitations. Having used RDBMSes like Postgres a lot, as well used Cassandra and DynamoDB in production, I would almost certainly not create a new app with DynamoDB as the primary DB. Even if you have an app where you expect to need to scale writes heavily, it's not going to be on all tables equally. For inst…

I can understand the sentiment and don't fault you for it. That said, I think you can definitely handle complex, relational patterns in DynamoDB pretty easily. It will take some work to learn new modeling patterns, but it's absolutely doable.

At what cost, though? RDBMS do provide a better querying interface with fewer pitfalls that invariably one encounters trying to fit a square peg in a round hole.

That said, I've seen people use DynamoDB as a timeseries database (modelling multi-dimensonal data with z-indices on top of the two dimensional partition-key and range-key pair), so it is definitely possible to be clever and practical at the same time.

Disclaimer: ex-AWS.

Post reply on HN