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

91–95 of 95 posts

Re: The DynamoDB Paper

#91

Post by deepGem »

jd_mongodb wrote: post #61
deepGem wrote: post #39

Earlier quoted context omitted.

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…

You seem to think MongoDB is eventually consistent. MongoDB is designed as strongly consistent database. You can choose to query a secondary and that will be eventually consistent but that is not the default behaviour.

I must have clarified, what I mean by strong consistency is that you have transactional support (2 phase commit). MongoDb is atomic, meaning every single document is strongly consistent. However, I stand corrected. They have introduced transactions as of 4.2.

Re: The DynamoDB Paper

#92

Post by _benedict »

jd_mongodb wrote: post #61
deepGem wrote: post #39

Earlier quoted context omitted.

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…

You seem to think MongoDB is eventually consistent. MongoDB is designed as strongly consistent database. You can choose to query a secondary and that will be eventually consistent but that is not the default behaviour.

I believe multi document transactions offer only causal consistency?

Re: The DynamoDB Paper

#93

Post by pfkurtz »

mabbo wrote: post #21

Rick Houlihan did a talk a few years ago about designing the data later for an application using dynamodb. The most common reaction I get from people I show it to- most of them Amazon SDEs who operate services that use Dynamodb- is "Holy shit what is this wizardry?!" https://youtu.be/HaEPXoXVf2k One of the biggest mistakes people make with dynamo is thinking that it's just a relational database with no relations. It'…

Thank you for this recommendation, I'm on a DynamoDB contract job and... really learning to think hard about key structure and designing for efficient querying, rather than efficient storage.

Re: The DynamoDB Paper

#94

Post by derekperkins »

solatic wrote: post #59
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…

Have you looked at Planetscale?

Re: The DynamoDB Paper

#95

Post by [deleted] »

derekperkins wrote: post #94
solatic wrote: post #59

Earlier quoted context omitted.

> 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…

Have you looked at Planetscale?

[deleted]
Post reply on HN