Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>This 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. </p> <p>A couple of things to note here:</p> <ul> <li>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.</li> <li>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).</li> <li>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.</li> </ul> <p>Check out the <a href="http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows-azure-tables.aspx" rel="noreferrer">How to get most out of Windows Azure Tables</a> 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.</p>
    singulars
    1. This table or related slice is empty.
    1. POUse the same PartitionKey and RowKey
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USMikeWo
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POUse the same PartitionKey and RowKey
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COIf I understood your point right, it will be better then to have a common ID (guid for example) as a partition key and then the row key will contain my unique customer ID and in this case I will still be able to get the customer by partionkey + rowkey but also make use of batches?
      singulars
      1. PO
      1. USuser2818430
    2. COI would not recommend keeping just one PartitionKey (e.g. `Users`) as that would defeat the whole purpose of partitioning. Assuming you have 100000 users and you set PartitionKey as `Users` and RowKey as unique id. When you search for users, table service will have to scan through those 100000 records to find matching user id. In this case you would be better off keeping unique id as the PartitionKey. HTH.
      singulars
      1. PO
      1. USGaurav Mantri
    3. CONo, I was only saying that you should be aware that batching only works with entities from the same partition. As Gaurav indicated if you put everything in the same partition you will have a drastic impact on the scalability of your system for the worse. What you are suggesting with a single customer per partition key is viable as long as you will always know the partition key.
      singulars
      1. PO
      1. USMikeWo
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload