It will perform a table scan regardless of whether or not your filter uses the RowKey. A Table Scan does not include the PartitionKey and is very inefficient because it searches all of the partitions that make up your table in turn for any matching entities.$filter=PartitionKey eq 'Sales' and LastName eq 'Smith' The PartitionKey value identifies a specific partition, and the property values select for a subset of the entities in that partition. Third best is a Partition Scan that uses the PartitionKey and filters on another non-key property and that may return more than one entity.
$filter=PartitionKey eq 'Sales' and RowKey ge 'S' and RowKey lt 'T' The PartitionKey value identifies a specific partition, and the RowKey values identify a subset of the entities in that partition.
Second best is a Range Query that uses the PartitionKey and filters on a range of RowKey values to return more than one entity. $filter=(PartitionKey eq 'Sales') and (RowKey eq '2') Such a query can use the indexes to locate an individual entity very efficiently by specifying both the PartitionKey and RowKey values. 
A Point Query is the most efficient lookup to use and is recommended to be used for high-volume lookups or lookups requiring lowest latency.Note that the filter syntax used in the examples below is from the Table service REST API, for more information see Query Entities. These result in the following general guidelines for designing Table service queries. The article Azure Table storage overview describes some of the key features of the Azure Table service that have a direct influence on designing for query.
The following examples assume the table service is storing employee entities with the following structure (most of the examples omit the Timestamp property for clarity): Column name How your choice of PartitionKey and RowKey impacts query performance
Optimizing queries for the Table service. How your choice of PartitionKey and RowKey impacts query performance. The topics covered in this section include: This section focuses on the key issues you must address when you design your tables for querying. For example, in a relational database it's often possible to address performance issues simply by adding indexes to an existing database: this is not an option with the Table service. Var rawMtlStock = table.ExecuteQuery(itemStockQuery) Ĭonsole.WriteLine("Item: ).With the Table service, it's important to get the design correct up front because it's difficult and expensive to change it later. TableQuery.GenerateFilterConditionForInt("Stock-in-hand", Quer圜omparisons.GreaterThan, 0))) TableQuery.GenerateFilterCondition("PartitionKey", Quer圜omparisons.Equal, "RawMaterial"), TableQuery itemStockQuery = new TableQuery().Where( Create the CloudTable object that represents the "items" tableĬloudTable table = client.GetTableReference("items") Retrieve the storage account from the connection stringĬloudStorageAccount storageAccount = CloudStorageAccount.Parse(ĬloudConfigurationManager.GetSetting("StorageConnectionString")) ĬloudTableClient tableClient = storageAccount.CreateCloudTableClient() Note that the result of the query is in IEnumerable form and so we can use LINQ operators on the result. We can construct a query using the TableQuery class and then execute the query against the Table using ExecuteQuery method.įor example, if the data had an integer property for Stock-in-hand, we can retrieve items in the RawMaterials category that is in stock using the following code.
0 kommentar(er)
