32 ms·
This kind of a design seems to make certain rows be accessed very often, no matter what data ends up actually being read. Doesn't this imply a hard bottleneck a
by eptcyka 8y ago
This kind of a design seems to make certain rows be accessed very often, no matter what data ends up actually being read. Doesn't this imply a hard bottleneck as, whilst DynamoDB IO operations can scale __infinitely__, they can only do so if the operations are spread over a random distribution of keys over which the backend can be partitioned, thus scaled horizontally, right?
- bboreham 8y agoYes, that was my reaction on reading this, that it will only scale as long as queries are well distributed across the customers, products, etc.
- shortj 8y agoThat limit is going to be pretty high. Adaptive capacity (or on-demand) gives you up to 3000 read capacity units / second and 1000 write capacity units / second per partition. The general solution if you think you are going to get to volume where that is not sufficient is to do something like add an additional integer (or other known symbol) to the end of the key. Ex: `key.1`, `key.2`, `key.3`. When doing operations you would have to run N operations across the key + symbol space. Not as elegant and you'll pay the additional computation for those queries, but since they can all be run in parallel it's not too bad in terms of latency. Now, if all you are doing is hammering away at a few rows, you are stuck for sure. DAX [1] or some other caching layer may be your only way out of that problem. [1] https://aws.amazon.com/dynamodb/dax/ https://aws.amazon.com/dynamodb/dax/