Which option will you choose?
Reason 4: Have you checked out the DynamoDB features lately?
DynamoDB, in the classical AWS style, was released with just bare-bone features. Add 3 config servers to it, and you are looking at a 12 node cluster. At 4 AM the conversation between a systems engineer and me is like following:
Engineer: Hey, got woken up by the pager, seems like CPU utilization is spiking, but requests are running fine. Many issues and bugs are only manifested when you test on the real deal. You still need monitoring for performance issues, but the things that need to be monitored are really few in numbers compared to MongoDB.
Reason 2: People don’t like to spend money on hardware (if they don’t have to)
I was in a meeting with a customer trying to understand their requirements to design the MongoDB cluster for them. Compare that to the two big upgrades DynamoDB did in last 12 months. They had about 1TB of data, and at peak they did about 1000 reads/second and 50 writes/second. Thus, if you looked at DynamoDB a year ago, and found it severely limiting in features, its time to look again. Can I just resolve this issue and look at it tomorrow?
Me: You woke me up to just ask this?
Why will you want your staff (or yourself) to have to go through this kind of conversation anytime during the day, let alone 4 in the morning? With DynamoDB, AWS engineers take care of such issues, not you. The phrase “But it worked in test cluster”, can be safely rejected.
If you are evaluating NoSQL databases, I suggest you give DynamoDB a sincere try. So either you need to fork out more money and get a test cluster that looks like production cluster in size and number of servers, or be ready for such bugs to slip though.
DynamoDB allows you to create the same cluster as prod but with lower throughput. The cost was about $3000 per month (this was before the recent price reductions).
If the DynamoDB was used, the starting capacity would have cost around $500, which is a huge reduction in cost. And as always, no upgrade is really as simple as the documentation states. You get calls from all your clients asking for when you can upgrade their existing MongoDB clusters to this latest and greatest version. Below I give five reasons to choose DynamoDB over MongoDB.
Reason 1: People don’t like being woken up in the middle of the night
One sure-shot way to motivate someone to rethink their priorities in life, and reconsider their choice in becoming an IT professional, is to hand them pager-duty for a MongoDB cluster. Thanks!!. Also, unlike MongoDB, one does not need to preprovision a lot of capacity, as DynamoDB allows rapid scaling up (and down), so unlike MongoDB, we would not have to preprovision a lot of extra capacity (and thus cost).
Also in case you get official MongoDB support, it costs extra and costs are relatively high, based on the number of hosts. If you have further questions about DynamoDB vs MongoDB, feel free to send me a comment below or at my email bhavesh at cloudthat.in.
If you liked the article please share it. I looked around but found nothing. In the MongoDB vs DynamoDB matchup, DynamoDB has a lot of brilliant features that help ease the pain of running NoSQL clusters. And as a seasoned professional you don’t want to make any changes to production during business hours, you know things can go wrong. Maintaining a MongoDB cluster requires keeping the servers up and running, keeping the MongoDB processes up and running, and performance monitoring for the cluster. Access controls to the tables and rows can now be controlled via IAM accounts which opens up so many usecases that are not possible in MongoDB.
The latest set of features improve querying by allowing to set filters. Check this image for example (time there are in UTC).
Screen Shot 2014-04-29 at 12.11.09 pm
In the middle of the night, a client’s MongoDB Cluster generated few automated CloudWatch alarms. This is also true for MongoDB, where for big production clusters with many shards and replicasets, most likely the QA cluster is just one machine. Thus even with lesser costs, you can test the real deal. You could not even have arbitrary indexing, the only index was the primary key. But since then DynamoDB has evolved rapidly with new feature like Local Secondary Indexes and recently Global Secondary Indexes that allow arbitrary keys to be indexed. With DynamoDB the AWS support that works for all other AWS services works for DynamoDB without having to buy additional support, which in comparison usually ends up being much lower.
Reason 3: Updating MongoDB version on a production system is not a good way to spend a Sunday
MongoDB releases version 2.6, and calls it their “best version yet”. They also wanted to avoid any downtime if and when they had to scale up, so preferred we pre-provisioned the capacity and started with capacity they would need at the end of the year when they had grown 3x. Your team will thank you when they can enjoy their sleep and weekends. Thus, you sacrifice your precious weekends to the altar of MongoDB upgrades. It was all seamless, and I was just notified that new features and better performance is available without me doing any real work. It was not that much better than a glorified hosted Memcache cluster. We designed a MongoDB cluster with three shards, and each shard having three replica-set thus 9 machines. If you are considering MongoDB or any other NoSQL databases, its a must that you consider DynamoDB. The reason why you decided to not use DynamoDB then, might have been fixed now.
Reason 5: Finally QA can test the real deal.
You have heard this before from QA personals, “But it worked in the Test cluster”. They were growing like crazy and expecting 3 times traffic growth in next one year.