Q71. How do Partitions work in storage services like Blobs and Queues?
When we talk of a Storage account, the concept of partition is also to be understood. Every object we store in the Storage account has a partition key. As discussed earlier, an object can be stored as a blob, table entity or a queue message. Partition key is used to access an object in a storage account. However, the definition of a partition key varies depending on the type of the object. If the object is a blob, then the partition key constitutes the Container Name and the Blob Name. If the object is an entity in a table, then the partition key constitutes the Table Name and Partition Key. If an object is a message in a queue, then the partition key is Queue Name.
The partition determines how Windows Azure storage load balances blobs, messages, and entities across servers to meet the traffic needs of these objects. The partition key is unique within the storage account and is used to locate a blob, message, or entity.
Partitions work differently in different storage services. By default, a single blob becomes a single partition, a single queue becomes a single partition.
Unlike in blob and queue storage services, in tables we have to decide on the Partition Key ourselves as we are responsible for the throughput we get from the system. We can partition a table using a specified key and Azure spreads the partitions across several nodes. We assign a Partition key and a Row key to an entity before inserting the entity into a table. I emphasize that care should be taken when deciding the Partition Key and Row Key. If we do not specify any partition key, a table will have a single partition.
The partition determines how Windows Azure storage load balances blobs, messages, and entities across servers to meet the traffic needs of these objects. The partition key is unique within the storage account and is used to locate a blob, message, or entity.
Partitions work differently in different storage services. By default, a single blob becomes a single partition, a single queue becomes a single partition.
Unlike in blob and queue storage services, in tables we have to decide on the Partition Key ourselves as we are responsible for the throughput we get from the system. We can partition a table using a specified key and Azure spreads the partitions across several nodes. We assign a Partition key and a Row key to an entity before inserting the entity into a table. I emphasize that care should be taken when deciding the Partition Key and Row Key. If we do not specify any partition key, a table will have a single partition.
