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

The DynamoDB Paper

brooker.co.za

Post reply on HN
Print view View original

51–60 of 95 posts

Re: The DynamoDB Paper

#51

Post by cogman10 »

ramraj07 wrote: post #18
bistablesulphur wrote: post #2

I'be been working with DynamoDB daily for a few years now, and whilst I like working with it and the specific scenario it solves for us, I'd still urge anyone thinking about using it to carefully reconsider whether their problem is truly unique enough that a traditional RDBMS couldn't handle it with some tuning. Theycan be unbelievably performant and give so much stuff for free. Designing application specifically for…

Could you elaborate on your (or a hypothetical) use case where dynamo db makes sense? I for one can never come up with something better served by rdbms or s3.

Lots of records (Billions), low/no relational linkage, The need to query/update records in different ways (IE, you need indexes), The need for HA and scaling (IE, perhaps you can be VERY bursty and read heavy).

It's not one size fits all, but at least in my line of work there are few instances where it's a pretty good fit.

Re: The DynamoDB Paper

#53

Post by ledauphin »

no_wizard wrote: post #33

How well does DyanmoDB scale when paired with AppSync and GraphQL? The selling point here being you can use GQL as your schema for the DB too and get automatic APIs for free

i've done this. it works really, really well to start off with - your API basically is your schema, and you're done.

There's definitely more work later on when your API and data model start diverging (which they always will). Overall it was a decent experience, and DynamoDB has made some really important QOL improvements over the last 5 years, too.

It's still not relational, which means it's very different and you'll be committed to a totally different way of thinking about things for a while.

Re: The DynamoDB Paper

#54

Post by ledauphin »

An underrated part of DynamoDB are its streams. You can subscribe to changes and reliably process those in a distributed way. If you're comfortable with the terms "at-least once delivery" and "eventual consistency", you can build some truly amazing systems by letting events propagate reactively through your system, never touching a data store or messaging broker other than DynamoDB itself.

It's not for everyone, but when you get a team up and running with it, it can be shockingly powerful.

Re: The DynamoDB Paper

#55

Post by manigandham »

deepGem wrote: post #39
Patrol8394 wrote: post #36

These days I’d probable take a closer look at spanner. It is a consistent and scalable db. It makes life much easier for developers. Like Cassandra, dynamodb requires the data model to be designed very carefully to be able to get the max out of them. More often than not, that simply adds more complexity; people often underestimate how much a sharded mysql/Postgres can scale. My default choice for the longest time: Po…

True. Spanner and the likes of Spanner, CockroachDB, YugaByte all are strongly consistent and scalable dbs. The greatest advantage IMO is the ability to just use SQL without having to worry about carefully designing a data model. What bothers me however is that these data stores are not truly relational data stores. They spin a relational layer on top of a scalable key-value data store. Is it necessary to use a stron…

What part of SQL requires not having to design a data model? What exactly do you mean by that?

And technically all relational databases are relational layers on top of a key/value subsystem. Splitting that apart and scaling the storage is how most of the NewSQL databases scale , from CRDB to Yugabyte to Neon.

Re: The DynamoDB Paper

#57

Post by kumarvvr »

A word of caution. The default limit for number of tables per AWS account, for DynamoDB is 2500.

Tables are a scarce resource and you want to use single table designs for each app.

The design of tables with DDB is fascinating. Once you understand the PK / SK / GSI dance, design becomes so intuitive.

Re: The DynamoDB Paper

#58

Post by kumarvvr »

bistablesulphur wrote: post #2

I'be been working with DynamoDB daily for a few years now, and whilst I like working with it and the specific scenario it solves for us, I'd still urge anyone thinking about using it to carefully reconsider whether their problem is truly unique enough that a traditional RDBMS couldn't handle it with some tuning. Theycan be unbelievably performant and give so much stuff for free. Designing application specifically for…

> Designing application specifically for DynamoDB will take _a lot_ of time and effort

Disagree with this. Your team could think of it as a document database, and you can have utility libraries that filter and sort based on PK / SK combinations to provide a seamless experience.

Re: The DynamoDB Paper

#59

Post by solatic »

bistablesulphur wrote: post #2

I'be been working with DynamoDB daily for a few years now, and whilst I like working with it and the specific scenario it solves for us, I'd still urge anyone thinking about using it to carefully reconsider whether their problem is truly unique enough that a traditional RDBMS couldn't handle it with some tuning. Theycan be unbelievably performant and give so much stuff for free. Designing application specifically for…

> give so much stuff for free

Interesting choice of words. Performance wise, sure. Money wise? I'm still waiting for a SQL database with pay-per-request pricing. The cost difference is enormous, particularly when you remember that you don't need to spend manpower managing the underlying hardware.

Engineering tradeoffs are more complicated than only considering raw scalability performance and "I can run it myself on a cheap Raspberry Pi".

Re: The DynamoDB Paper

#60

Post by grogers »

fubbyy wrote: post #5
bistablesulphur wrote: post #2

I'be been working with DynamoDB daily for a few years now, and whilst I like working with it and the specific scenario it solves for us, I'd still urge anyone thinking about using it to carefully reconsider whether their problem is truly unique enough that a traditional RDBMS couldn't handle it with some tuning. Theycan be unbelievably performant and give so much stuff for free. Designing application specifically for…

I think it also depends on the system you’re using it on. I think one of the biggest advantages of DDB is that is scales so well (with good design to avoid hot partitions). Afaik, RDBMS simply cannot scale in the same way due to their design. Yes, they can scale somewhat, but as you said it requires lots of tuning, and you’ll still reach a hardish limit.

One partition of DDB is incredibly tiny compared to one partition of an RDBMS. You can push that one partition of RDBMS pretty far before you're forced to design sharding into your system. With DDB you are basically forced to design sharding into your partition keys up front or you will have hot partition issues. This is by far the most common problem I see with teams using DDB, so brushing it off as "with good design to avoid hot partitions" is understating the scope of the problem.
Post reply on HN