An expensive coffin for you NoSQL data.
October 13, 2017
An expensive coffin for you NoSQL data.
Score 4 out of 10
Vetted Review
Verified User
Overall Satisfaction with Amazon DynamoDB
We use dynamodb for to store and track millions of email messages sent by our sass product. Each email is unique, and in order to maintain a full record of our transactions with clients, we store, and recall each message that was ever sent using dynamodb. Because of the sheer scale and data size requirements it makes it very difficult to use traditional methods of recall, especially when you want the actual text of the email to be part of the database and not stored in offline storage.
- Recall on primary hashes is very fast, with HTTP latency over the network we were regularly able to call up records in the 20ms range from a database of millions of records
- Like other NoSQL databases Dynamo lets you easily and quickly add fields to each record without having to define a full schema.
- Pricing is quite affordable as long as you are efficient with your queries. You really need to be doing hash lookups rather than scans since Amazon charges you per record accessed.
- Query "language" leaves much to be desired. If you're coming from a database like MongoDB or SQL you'll find it extremely difficult to get data back out of the system without breaking the bank.
- Because querying is poor, often the only way to get data out of arbitrary fields is by scanning the records – but the pricing model for this is cost prohibitive. This means you frequently need additional architecture to keep track of where data is stored in the hash table. While this is an issue for lots of NoSQL database, DynamoDB is probably the worst offender I've used to date because of the pricing model.
- Amazon does offer a local version of DynamoDB you can run in development, but its an extremely clunky and very hard to integrate into any kind of continuous integration.
- We were able to achieve our goal using Amazon – store every single email our system that has ever been sent in fluid database for long term recover without significantly impacting query times at scale.
- We have been unable to effectively add additional features using the data set because of the pricing structure and incurred cost involved with performing repeated scans over the dataset.
- MongoDB and Redis Cloud
9/10 times I would recommend using MongoDB over DynamoDB. The only real benefit of DynamoDB over MongoDB is that it's already deeply nested in the Amazon ecosystem with tight integration with other AWS tools. Working with Amazons sdks is clunky compared to Mongo, it lacks a truly expressive query language, and the pricing makes your data inflexible.