Azure Cosmos DB 表中查找表的分区键

Question

I have a very simple lookup table I want to call from an Azure function.

Schema is incredibly simple: Name | Value 1 | Value 2 Name | Value 1 | Value 2

Name will be unique, but value 1 and value 2 will not be. There is no other data in the lookup table.

For an Azure Table you need a partition key and a row key. Obviously the rowkey would be the Name field.

What exactly should I use for Partition Key?

Right now, I'm using a constant because there won't be a ton of data (maybe a couple hundred rows at most) but using a constant seems to go against the point.

Answer 1

This answer applies to all Cosmos DB containers, including Tables.

When does it make sense to store your Cosmos DB container in a single partition (use a constant as the partition key)?

• If you are sure the data size of your container will always remain well under 10GB.
• If you are sure the throughput requirement for your container will always remain under 10,000 RU/s (RU per second).

If either of the above conditions are false, or if you are not sure about future growth of data size or throughput requirements then using a partition key based on the guidelines below will allow the container to scale.

How partitioning works in Cosmos DB

Cosmos groups container items into a set of logical partitions based on the partition key. These logical partitions are then mapped to physical partitions . A physical partition is the unit of compute/storage which makes up the underlying database infrastructure.

You can determine how your data is split into logical partitions by your choice of partition key. You have no control over how your logical partitions are mapped to physical partitions, Cosmos handles this automatically and transparently.

Distributing your container across a large number of physical partitions is the way Cosmos allows the container to scale to virtually unlimited size and throughput.

Each logical partition can contain a maximum of 10GB of data. An unpartitioned container can have a maximum throughput of 10,000 RU/s which implies there is a limit of 10,000 RU/s per logical partition.

The RU/s allocated to your container are evenly split across all physical partitions hosting the container's data. For instance, if your container has 4,000 RU/s allocated and its logical partitions are spread across 4 physical partitions then each physical partition will have 1,000 RU/s allocated to it, which also means that if one of your physical partitions is under a heavly load or 'hot', it will get rate-limited at 1,000 RU/s, not at 4,000. This is why it is very important to choose a partition key that spreads your data, and access to the data, evenly across partitions.

If your container is in a single logical partition, it will always be mapped to a single physical partition and the entire allocation of RU/s for the container will always be available.

All Cosmos DB transactions are scoped to a single logical partition, and the execution of a stored procedure or trigger is also scoped to a single logical partition.

How to choose a good partition key

Choose a partition key that will evenly distribute your data across logical partitions, which in turn will help ensure the data is evenly mapped across physical partitions. This will prevent 'bottleneck' or 'hot' partitions which will cause rate-limiting and may increase your costs.

Choose a partition key that will be the filter criteria for a high percentage of your queries. By providing the partition key as filter to your query, Cosmos can efficiently route your query to the correct partition. If the partition key is not supplied it will result in a 'fan out' query, which is sent to all partitions which will increase your RU cost and may hinder performance. If you frequently filter based on multiple fields see this article for guidance.

Summary

• The primary purpose of partitioning your containers in Cosmos DB is allowing the continers to scale in terms of both storage and throughput.
• Small containers which will not grow significantly in data size or throughput requirements can use a single partition.
• Large containers, or containers expected to grow in data size or throughput requirements should be partitioned using a well chosen partition key.
• The choice of partition key is critical and may significantly impact your ability to scale, your RU cost and the performance of your queries.