title: DynamoDB partitioning with a numeric hash key. Does this key scheme keep uniform data access?
body: <p>The documentation for Dynamodb is reasonably clear on how to evenly spread data across partitions by managing your hash/range key naming scheme.</p>
  
  <p><a href="http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.UniformWorkload" rel="nofollow">http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.UniformWorkload</a></p>
  
  <p>Due to this I tend to more often than not use unique alphanumeric hash keys.  However in this instance we have a situation where the actual size of the key itself is of great importance since the hash key chosen in dynamodb will be replicated over and over again in various streams in <code>redis</code>.</p>
  
  <p>Therefore we need a key which suits both <code>dynamodb</code> from a data access/partitioning point of view as well as <code>redis</code> from a pure key size point of view.</p>
  
  <p>With this in mind we have decided to keep an incrementing counter in <code>redis</code> and use a single <code>NUMBER</code> hash key for dynamodb items.  Incrementing the <code>redis</code> counter each time we insert a new item in to dynamodb.</p>
  
  <p>These integer keys are very nicely compressed in <code>redis</code> and from our testing yield storage space improvements in excess of 300-400% over unique string based ID's (since these ID's could potentially be pushed into 100's of streams, all stored in <code>redis</code> lists/zsets.</p>
  
  <p>To my understanding though, this is not good for dynamodb since a single incrementing hash key:</p>
  
  <pre><code>101
  102
  103
  104
  </code></pre>
  
  <p>etc...</p>
  
  <p>Would be slow on writes when inserting multiple items and given our access pattern, we would expect groups of these keys to be retrieved together.</p>
  
  <p>In order to work around this we are thinking of concatenating a random number onto the end of the hash key.</p>
  
  <p><code>(float)$itemId . '.' . mt_rand(0, 200)</code></p>
  
  <p>Resulting in keys like so:</p>
  
  <pre><code>101.26
  102.199
  103.87
  104.5
  </code></pre>
  
  <p>Using these keys we would still get the storage improvements in <code>redis</code> and we also manage to preserve the insertion order (meaning that we don't need to store a timestamp)...</p>
  
  <p>However I am not completely clear on how dynamodb would manage and partition these.</p>
  
  <p>So my question is, would single hash keys as shown above be optimal and encourage dynamodb to partition our table effectively and ultimately allow us to meet or throughput allocations.</p>
  
  <p>Thanks in advance.</p>