3 ms·
Similar experience with Dynamo here: it's very easy to get into a situation where it's unusable (rejecting requests) unless you pre-provision enough capacity. T
by jbergknoff 8y ago
Similar experience with Dynamo here: it's very easy to get into a situation where it's unusable (rejecting requests) unless you pre-provision enough capacity. The act of scaling up capacity often takes 5-20 minutes, and then there are the limits on how often you can scale. The backup/restore options are very poor. There's no good way to clear a table besides deleting and recreating it, which can be a problem when there are stream listeners. The tooling around Dynamo, both first party and third party, is also pretty shabby.
Maybe I'm just using it wrong. I wish Dynamo came close to its apparent potential.
- AmericanChopper 8y ago>Maybe I'm just using it wrong. I wish Dynamo came close to its apparent potential. Maybe, but you might also be using it for the wrong thing. Any business logic that requires table scans (which are perfectly fine on RDBMS), is going to suck in any document database. The way you win at Dynamo is by making sure that one user operation is as close to one Dynamo call as you can make it. If your workload can't be designed to suit that paradigm, then Dynamo will only bring you pain and suffering. That said though, migrations are terrible in Dynamo. Altering a table will often involve creating a new one, backfilling it, and then cutting over. Which you have to implement your own logic for. Also, think the GSI limit is 5? In practice it's actually 4, because if you want to recreate a GSI, you need to create a new one, and then drop the old one, so you have to keep one spare to accomodate that process.
- k__ 8y agoSome time ago I read they revamped the provisioning/boosting algorithms, to get around some of the issues.