none
Is this how partitioning works, scale/no scale within table storage?

    Pertanyaan

  • If entities stored inside a table uses 2 partition keys "A" and "B", will they then always be splitted into seperate nodes/servers or is it only a description of how data should be places across seperate nodes/servers if performance becomes an issue?

    Best regards

    Rasmus


    Developer

    15 April 2012 20:19

Jawaban

  • Hi,

    Tables are partitioned to support load balancing across storage nodes. A table's entities are organized by partition. A partition is a consecutive range of entities possessing the same partition key value. The partition key is a unique identifier for the partition within a given table, specified by the PartitionKey property.

    Accroding to your description, i think different partitionKey does not mean they "must" splitted into seperate nodes/servers. The different partition keys may stored in the same server, but the same partitionKey rows were maintained by partitionKey server to improve query performance.

    More details:

    http://msdn.microsoft.com/en-us/library/windowsazure/dd179338.aspx

    In your situation, I think if you set the "eventID" as the partitionKey of "user" table, it's beneficial of query the users who attend in this event (via EventID), but if you need query how many events a user attend, the "eventID" partitionKey may not efficiently (here userId may a good potential partitionKey), so i think partitionKey is decide by your design, you can observe with query method is the most common one, and set the appropriate partitionKey.

    Hope this helps.


    Please mark the replies as answers if they help or unmark if not. If you have any feedback about my replies, please contact msdnmg@microsoft.com Microsoft One Code Framework

    16 April 2012 3:49

Semua Balasan

  • The guarantee is that all rows of a partition will be on the same node. (Although all rows of one or more or all partitions can be on the same node if the node can accommodate them).

    Hence the requirement is that the size of a partition should not be so large, that all its rows cannot be accommodated on a single node.

    15 April 2012 20:37
  • Yes, meaning I can easily put a lot lets say "events" inside an eventtable, assign each event a uniqueue partitionkey, and if needed the events table will be scaled into more nodes based on the partition keys. 

    Best regards Rasmus Christensen

    15 April 2012 20:54
  • Hi,

    Tables are partitioned to support load balancing across storage nodes. A table's entities are organized by partition. A partition is a consecutive range of entities possessing the same partition key value. The partition key is a unique identifier for the partition within a given table, specified by the PartitionKey property.

    Accroding to your description, i think different partitionKey does not mean they "must" splitted into seperate nodes/servers. The different partition keys may stored in the same server, but the same partitionKey rows were maintained by partitionKey server to improve query performance.

    More details:

    http://msdn.microsoft.com/en-us/library/windowsazure/dd179338.aspx

    In your situation, I think if you set the "eventID" as the partitionKey of "user" table, it's beneficial of query the users who attend in this event (via EventID), but if you need query how many events a user attend, the "eventID" partitionKey may not efficiently (here userId may a good potential partitionKey), so i think partitionKey is decide by your design, you can observe with query method is the most common one, and set the appropriate partitionKey.

    Hope this helps.


    Please mark the replies as answers if they help or unmark if not. If you have any feedback about my replies, please contact msdnmg@microsoft.com Microsoft One Code Framework

    16 April 2012 3:49