Amazon DynamoDB Transactions

Post by wahnfrieden » Wed, Nov 28, 2018, 5:29 AM UTC

scarface74 wrote: post #21

abalone wrote: post #11

Any experience with using Aurora in place of DynamoDB? A couple years ago there was an interesting tidbit at re:Invent about customers moving from DynamoDB to Aurora to save significant costs.[1] The Aurora team made the point that DynamoDB suffers from hotspots despite your best efforts to evenly distribute keys, so you end up overprovisioning. Whereas with Aurora you just pay for I/O. And the scalability is great.…

Whether NoSQL is the best approach and whether DynamoDB is the best approach are two separate issues. I find DynamoDB too limiting with the way that it handles indexing, read and write capacity, etc. compared to traditional NoSQL databases like ElasticSearch and Mongo. That being said, one advantage of DynamoDB is that it is API based and you can make a true serverless web app where all of the logic is on the client,…

Post by kenhwang » Wed, Nov 28, 2018, 6:20 AM UTC

awinder wrote: post #27

abalone wrote: post #24

Earlier quoted context omitted.

Oh cool. For those reading along this is titled "How Amazon DynamoDB adaptive capacity accommodates uneven data access patterns (or, why what you know about DynamoDB might be outdated)". Is this a new feature?

Yeah I should have elaborated a bit. I believe adaptive capacity was announced at re:invent in 2017 and may have released shortly after / maybe early 2018. The feature is getting a lot more press & push from AWS lately though for sure.

Post by polskibus » Wed, Nov 28, 2018, 6:24 AM UTC

jared2501 wrote: post #12

I'd be interested to see comparisons/benchmarks against FoundationDB. DynamoDB transactions make dynamo a serious alternative to FDB now. I can see the two manage advantages for FDB being: 1) you can deploy it on premise (which is potentially important for some B2B companies), 2) it shuffles data around so that hot-spotting of a cluster is eliminated (which dynamo appears to still suffer from).

Post by abalone » Wed, Nov 28, 2018, 7:30 AM UTC

orthecreedence wrote: post #25

coder543 wrote: post #14

Earlier quoted context omitted.

I personally recommend using a SQL database until you're absolutely positively sure you don't need one, for many reasons. But, as far as the "you end up overprovisioning" because of hotspots thing, DynamoDB does offer autoscaling these days, which should alleviate a lot of provisioning-related headaches and save you money compared to the provisioning you would have done with DynamoDB, from what I understand.

We use a hybrid. We process a lot of incoming data and dump most of it into dynamo (it's ephemeral so the TTL feature is nice) and if we get capacity errors (Dynamo takes a while to scale up sometimes) we just dump our objects in the DB. The end result is we keep a huge amount of writes off our DB for processing incoming largish objects. The amount of data it stores would cost an arm and a leg to put into redis. Gran…

Post by [deleted] » Wed, Nov 28, 2018, 8:09 AM UTC

coder543 wrote: post #14

abalone wrote: post #11

Any experience with using Aurora in place of DynamoDB? A couple years ago there was an interesting tidbit at re:Invent about customers moving from DynamoDB to Aurora to save significant costs.[1] The Aurora team made the point that DynamoDB suffers from hotspots despite your best efforts to evenly distribute keys, so you end up overprovisioning. Whereas with Aurora you just pay for I/O. And the scalability is great.…

I personally recommend using a SQL database until you're absolutely positively sure you don't need one, for many reasons. But, as far as the "you end up overprovisioning" because of hotspots thing, DynamoDB does offer autoscaling these days, which should alleviate a lot of provisioning-related headaches and save you money compared to the provisioning you would have done with DynamoDB, from what I understand.