Comment by larrik
9 years ago
I used DynamoDB for an inherited project around the time I had gotten really good with MongoDB. I don't have any idea why anyone would ever use DynamoDB. It's like Mongo, without any of the good parts, that you can't run locally or any non-Amazon server. I don't see the benefit.
Edit: Specifically, I was using some pretty advanced aggregation stuff. At the time I used it, DynamoDB had zero aggregation whatsoever.
The reasons we use it * doesn't require any setup (no provision servers, maintining backups, etc) * automatic backups * practically free during development * scales when you need it too
That said, we've run into issues with the partitioning. If we were given access to the partition information and the ability to reduce partitions when needed, that would solve those problems.
Mind sharing what issues? A few keys are the target of a disproportionate amount of transactions?
Correct, our read/write access isn't spread out. So, before knowing how the partitions worked, we increased our read/write throughput, this caused the partitions to increase, so now our throughput that was spread out across the entire table, was split between 2 partitions. This caused even more throttling.
Your list formatting didn't quite work.
I also have done 3 years of MongoDB before I (unwillingly) wrote an app with it... worst development experience I've ever had. I wouldn't have used it were it not for my corporate overlords at the time.
My new rule of thumb: Use plain databases for most things and only use DynamoDB if there's a precise feature in your system that it is well suited for.
DynamoDB is a horrible general use database.
It's specifically not a general use database, so it's not surprising that it doesn't have general use database features. If you want that on AWS, use RDS or Aurora. If you need to scale in certain ways, then Dynamo can certainly be worth the restrictions it imposes, because it is very scalable.
You had a horrible experience with MongoDB but you are drawing a conclusion about DynamoDB? Am I missing something?
I think your parent commenter meant "3y experience using Mongo before having to use it [- DDB, subject of thread -] ..."
By "plain database" do you mean a relational database?
Care to elaborate? MongoDB for app development on paper seems like a great solution.
The NOSQL model fits great with a Restful API layer. The process of getting and posting data over HTTP should be a lot simpler with Restful API/MongoDB when compared to relational database solution.
I know Restful APIs are not perfect either, so care to fill in the blanks of why its was the worst dev experience for you.
If you don't understand why anyone would use DynamoDB then MongoDB is probably perfect for you.
I used MongoDB in the past too. Now, I'm using Elasticsearch as a document store. Aggregations are good, and you can do some very advanced stuff with it (geographic clustering, scan left, range and exact match, range buckets, histograms). Of course it comes with a set of limitations, but it might be worth your time to investigate (especially if you want to use it also for full text search).
I've actually become quite familiar with Elasticsearch since then, whereas I stopped using Mongo (that project died). ES is indeed very powerful.
To be fair, you can run DynamoDB locally: https://docs.aws.amazon.com/amazondynamodb/latest/developerg...
DynamoDB-Local is a service that implements DynamoDB's API, including its query language, datatypes, and grammar, but stores everything in SQLite. It's great for playing with the API or substituting a mock implementation that doesn't drain your wallet, but it's very unlikely have the backend implementation and the performance characteristics -- or even all of the exact bugs -- of "real" DynamoDB.
last time I used this, it had many significant differences from the real DynamoDB. Different enough that I don't really understand what purpose DynamoDB Local is actually supposed to serve.
Ah, I wonder if this was true a few years ago (early 2014) when I was working with it.
DynamoDB being part of the AWS ecosystem is a massive benefit.
I like the way you spelled "lock-in". ;-)
I dislike your sarcastic winky face, but I agree with the sentiment.
Unless you plan on handing amazon your money forever, you should always steer for agnostic solutions you have the ability to host yourself.
As much as it may not 'scale' if you manage to get a passive income with decent understanding of load, then purchasing hardware is almost certainly cheaper for you.
Cheaper is good, it means more return so you can invest that income in your new project (and pay amazon for easy scaling again, if you want). But removing that ability not only locks you into their platform which may change prices at any time... it also means you can't move to self-hosting when the time is right and save quite a lot of money.
8 replies →
It's a fair point, but when you stick to the same ecosystem you save a lot of time in terms of setup for credentials, monitoring, backups, devops etc.
You can run it locally for development. Just look for dynamodb-local images on the docker hub.
Dynamodb has performance guarantees and you don't have to get into nightmare of maintaining MongoDB cluster.