https://stackoverflow.com/questions/19671357
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianThis will certainly make your customer look up quick. The RowKey can be an empty string so you technically don't have to make PartitionKey and Rowkey match if you will have a unique partition for every customer.
A couple of things to note here:
- You're giving up adding customers in batch or updating them in batch. Since only entities in the same partition can be worked with in batch, if you have a single entity partition scheme there will be no batches. Given what you've outlined above I don't think this will bother you.
- Any sort of range query against the partitionKey, such as all customers between 1 and 200, will end up possibly spanning multiple partition servers making this a very inefficient query. Again, if you are only going to look a customer up one at a time and never in groups you should be fine. Might want to think about that scenario where you have to go add a property to EVERY customer in your system and how you would handle that if it became necessary (a multi-threaded updater with a set of known customer IDs may be just fine, but you should at least think about it).
- Try avoid an append only pattern. Meaning if your customer IDs are consecutive then as you add them they will initially be on the same partition server. Only after a segment of them get hot will they be moved off to another server. It's better to do a hash of the ID and use that as the PartitionKey which will cause them to be scattered more across multiple partition servers if you start really hammering on them. You may not actually see that depending on your load.
Check out the How to get most out of Windows Azure Tables article on choosing partition keys. You'll see most of what I said here is there as well (one of the places I learned it from) plus more.
