Earlier quoted context omitted.
I would imagine the use of AWS Lambda might be a pretty decent incentive to use DynamoDB. I'm guessing that stateless DynamoDB queries are faster to fire off than dealing with Postgres or MySQL connection setup and teardown.
I'm not familiarized with DynamoDB, but why would connecting to it be any faster than connecting to Postgres or MySQL?
There are very few suitable use cases for DynamoDB
51–60 of 146 posts
Re: There are very few suitable use cases for DynamoDB
#52Ended up switching to RethinkDB and haven't looked back - far better query syntax/language (REQL) and we can organise the JSON content just how we want it.
Re: There are very few suitable use cases for DynamoDB
#53Whenever I read about NoSQL systems, I'm always left a unsure about its use-cases. I've only worked on systems where a traditional RDBMS made the most sense. How do you identify when it's appropriate to reach for one of the many NoSQL tools?
I've had the suspicion that many applications that leverage NoSQL tools are usually used in conjunction with a relational database, and not in isolation. Based on my limited understanding, I can at least wrap my head around a few ways in which this could probably help. Am I off the mark here? One of the points I struggle with is that once you're storing data across multiple data stores, maintaining data integrity becomes much harder.
Re: There are very few suitable use cases for DynamoDB
#54article that outlines gotchas of Bigtable
article you probably shouldn’t use Bigtable
article the amount of money we could've saved using PG and not rewriting things 3 times.
anything up to 10-15TB there are very few reasons not to use something like PG
Re: There are very few suitable use cases for DynamoDB
#55Many of the comments here are saying that the author's use-case wasn't a good one for DynamoDB. Can anyone share some simple approachable resources that talk about the kinds of use-cases where these tools make sense? Whenever I read about NoSQL systems, I'm always left a unsure about its use-cases. I've only worked on systems where a traditional RDBMS made the most sense. How do you identify when it's appropriate to…
Re: There are very few suitable use cases for DynamoDB
#56Re: There are very few suitable use cases for DynamoDB
#57I've seen two large usages of DynamoDB at two different companies, and for what it's worth, in both cases we've had similar trouble as the author. In one case we ended up ripping it out and moving to a sharded Postgres scheme, and in the other we've left in place for now because a migration will be such a monumental effort, but it's pretty much universally maligned. Fundamentally, the problem seems to be that choosin…
Why on earth don't they hash the key to improve the key distribution?
Re: There are very few suitable use cases for DynamoDB
#58Earlier quoted context omitted.
Why on earth don't they hash the key to improve the key distribution?
How would that help? The same user id will still hash to the same thing.
Re: There are very few suitable use cases for DynamoDB
#59Earlier quoted context omitted.
Each shard is 10GB. The unit of scale is a shard. You can have as many shards as you want.
It's one shard per node though, right? So you're talking about SERIOUS cost when you want to store _actual_ big data.
Re: There are very few suitable use cases for DynamoDB
#60I've seen two large usages of DynamoDB at two different companies, and for what it's worth, in both cases we've had similar trouble as the author. In one case we ended up ripping it out and moving to a sharded Postgres scheme, and in the other we've left in place for now because a migration will be such a monumental effort, but it's pretty much universally maligned. Fundamentally, the problem seems to be that choosin…
Why on earth don't they hash the key to improve the key distribution?
> DynamoDB uses the partition key value as input to an internal hash function; the output from the hash function determines the partition where the item is stored.