More about "partitionkey" & "rowkey" in Windows azure table Storage

Windows azure table storage provides shortcuts for massive storage and load balancing.

This is a graph that references the msdn table storage entity.

Unlike relational databases, an azure table can store different types of entities.

Each table row has three system attributes: partitionkey, rowkey, and timestamp.

Timestamp is maintained by the system, and the time at which the record is last operated is UTC.

 

Without the limitations of relational databases, you can focus more on class design.

How can we make full use of table Storage Service?

What kind of query is more optimized?

After reading this video (Windows azure tables and queues deep dive), I feel a little bit:

Reasonable Design of partitionkey and rowkey will effectively improveProgramEfficiency.

 

A combination of partitionkey and rowkey can uniquely locate an object row.

Windows azure table service can use partitionkey for load balancing.

Data with the same partitionkey is stored in the same zone.

Only data operations with the same partitionkey can start transaction operations.

Data (zones) of different partitionkeys may be located on different servers.

Use reasonable partitionkey and rowkey queries to avoid full table scan.

 

Example:

Entity video, including category, subcategory, ID, ispublic... .

Possible:

The format of partitionkey is: category.

In this way, data of the same category can be stored in the same zone.

Possible:

Partitionkey format: category_subcategory

In this way, if a category contains too much data for easy query, more areas will be stored.

 

The table storage structure needs to be designed according to the specific business to achieve relative optimization.

 

Assume that the format of partitionkey is category_subcategory.

Use partitionkey to query and avoid full table scan:

VaR query = _ servicecontext. videotable. astableservicequery (). Where (C => C. partitionkey = "sport_china ");

In this way, you can quickly retrieve the data of Category = "sport" & subcategory = "China.

Imagine if the partitionkey contains other meaningless values (such as random videos ),

To retrieve data such as Category = "sport" & subcategory = "China", you will have to scan the entire table:

VaR query = _ servicecontext. videotable. astableservicequery (). Where (C => C. Category = "sport" & C. subcategory = "China ");

 

What should I do if I have to scan the entire table?Parallel Query.

If the table is large, Windows azure can only return 1000 rows (or process 5 seconds) at a time (currently, the entire azure platform is continuously updated .)

Parallel query also becomes very easy in. net4.0. In this case, consider it as much as possible.

 

In addition, do not test the performance of azure table Storage Service in a local simulated environment. This is not an order of magnitude as it is actually deployed on the cloud.

Make sure that the application is available, and optimize the performance on the cloud as much as possible.

The difference between the table Storage Service and the cloud table Storage Service in the local simulated environment is much different from the difference between the local call of SQL azure and the cloud call of SQL azure.

 

When there is a large amount of data storage and there is no need for strict relational DB, we should consider Table Storage Service as much as possible, rather than SQL azure. Regardless of program considerations or costs ^_^.

 

I am only familiar with table storage service.