The DynamoDB Paper
brooker.co.za
The DynamoDB Paper
1–10 of 95 posts
Re: The DynamoDB Paper
#2I'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 DynamoDB will take _a lot_ of time and effort. I think we could have saved almost a third of our entire development time had we used more of the boring stuff.
Re: The DynamoDB Paper
#3I'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…
To be fair, you can end up spending a lot of time on the boring stuff as well.
Re: The DynamoDB Paper
#4I'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…
Is there a specific reason why you say "Designing application specifically for DynamoDB will take _a lot_ of time and effort".
Are you talking about migrating from RDBMS to DynamoDB?
Coz, my experience with DynamoDB designing was very similar to any other NoSQL DB.
Re: The DynamoDB Paper
#5I'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.
Re: The DynamoDB Paper
#6I'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…
Is there a specific reason why you say "Designing application specifically for DynamoDB will take _a lot_ of time and effort". Are you talking about migrating from RDBMS to DynamoDB? Coz, my experience with DynamoDB designing was very similar to any other NoSQL DB.
I mean if you go the single table route… https://aws.amazon.com/blogs/compute/creating-a-single-table...
Re: The DynamoDB Paper
#7I'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…
Is there a specific reason why you say "Designing application specifically for DynamoDB will take _a lot_ of time and effort". Are you talking about migrating from RDBMS to DynamoDB? Coz, my experience with DynamoDB designing was very similar to any other NoSQL DB.
A lot is transferrable to NoSQL and key-value in general, though DDB has plenty of quirks of it's own. Understanding your problem really is the key. A lot of problems turn out to be quite relational after all
You definitely can build just about anything with DDB, it's often just not worth the time when most can be solved by existing tools
Re: The DynamoDB Paper
#8I'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…
If you have a database access layer then structuring your application shouldn't be that different. I wouldn't deal with the database directly unless I had a really good reason or the abstraction layer didn't support the query I was trying to run.
Re: The DynamoDB Paper
#9I'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…
If you have a database access layer then structuring your application shouldn't be that different. I wouldn't deal with the database directly unless I had a really good reason or the abstraction layer didn't support the query I was trying to run.
DynamoDB is amazing, but not very flexible once you have designed your database. No abstraction layer will allow you to run queries ad-hoc in a performant way.
Re: The DynamoDB Paper
#10Nice write-up from Marc. This definitely hits on the most common problems distributed systems face. I haven't read the paper yet but it is pretty cool they published this and talk about changes over time.
1. Managing 'heat' in the system (or assuming that you'll have an uniform distribution of requests)
2. Recovering a distributed system from a cold state and what that implies for your caches.
3. The obvious one that people that do this type of thing spend a lot of time thinking about: CAP theorem shenanigans and using Paxos.
Reminds me of the Grugbrained developer on microservices: https://grugbrain.dev/#grug-on-microservices
Good luck getting every piece working on the first major recovery. My 100% unscientific hunch is that most folks aren't testing their cold state recovery from a big failure, much how folks don't test their database restoration solutions (or historically haven't).