11

I have created a Cosmos DB collection with the partition key. Since it is a dev environment I have reduced the throughput to 1000. Now I'm getting the below error.

Message:

"Errors":["Partition key reached maximum size of 10 GB"]

Azure Cosmos DB containers can be created as fixed or unlimited. Fixed-size containers have a maximum limit of 10 GB and 10,000 RU/s throughput. To create a container as unlimited, you must specify a minimum throughput of 2,500 RU/s.

Now I have increased the throughput to 2500. But still, I'm getting the same error.

Long Luong
  • 764
  • 2
  • 14
  • 28
Sarva
  • 313
  • 1
  • 3
  • 13

3 Answers3

21

UPDATE - 11 May, 2020

Microsoft has recently increased the capacity of a logical partition from 10 GB to 20 GB. Please see this for more details: https://learn.microsoft.com/en-us/azure/cosmos-db/concepts-limits

I emailed Aravind Krishna, who is an engineer on the Azure Cosmos DB team and asked for clarification on this point. This is a summary of his answer:

In Cosmos DB, there are physical and logical partitions. Within a Collection, all documents that share the same value for the partition key will live within the same logical partition. One or more logical partitions occupy a physical partition. As developers, the physical partitioning is irrelevant; we only have control over what belongs in a logical partition.

Regardless of whether a Collection is Fixed (10GB) or Unlimited, the 10GB limit applies to a logical partition. Period.

So Sarva, you will need to either rethink your partition key or implement rolling logs to ensure that data within your debug log partition doesn't exceed the 10GB partition limit.

CHEEKATLAPRADEEP
  • 12,191
  • 1
  • 19
  • 42
Rob Reagan
  • 7,313
  • 3
  • 20
  • 49
  • Thank you Rob. I need to think about it. – Sarva Jan 02 '18 at 07:13
  • How I can get a current size (used) for each partition key for avoiding this issue? Anh How I can get the maximum size for each partition key? (because maybe azure will change the maximum of each partition key in the future?) – Duc Nguyen Mar 15 '19 at 10:04
  • @DucNguyen should be able to find that information on the Metrics blade of your Cosmos instance in the Azure portal. Maximum size, as already stated, is 10GB per logical partition. It might change in future but that would likely be announced well ahead of time and you absolutely should not base your current plans on something that might or might not happen. – Steve Pettifer Apr 16 '19 at 10:18
  • This limit has been recently raised to 20 GB. Reference: https://learn.microsoft.com/en-us/azure/cosmos-db/concepts-limits – juunas May 11 '20 at 13:24
  • 1
    Hi I found this in the Microsoft learning content. "When the capacity of a logical partition gets close to the maximum storage, Azure Cosmos DB allocates another physical partition. Azure Cosmos DB seamlessly splits the logical partitions, the groups of documents with the same partition key value, among the physical partitions." https://learn.microsoft.com/en-us/learn/modules/monitor-and-scale-cosmos-db/5-partition-lesson – Rishanthakumar Jun 14 '20 at 15:23
3

UPDATE - 11 May, 2020

Microsoft has recently increased the capacity of a logical partition from 10 GB to 20 GB. Please see this for more details: https://learn.microsoft.com/en-us/azure/cosmos-db/concepts-limits

The reason you're getting this error is because even though unlimited collection (a.k.a. partitioned collection) does not have size restriction a partition in that collection have and that is currently 10 GB. Since you have reached that limit for your partition, you're getting this error. From this link (Question 6):

It is important to choose a partition key property that has a number of distinct values, and lets you distribute your workload evenly across these values. As a natural artifact of partitioning, requests involving the same partition key are limited by the maximum throughput of a single partition. Additionally, the storage size for documents belonging to the same partition key is limited to 10GB. An ideal partition key is one that appears frequently as a filter in your queries and has sufficient cardinality to ensure your solution is scalable.

Only solution that I could think of is to recreate the collection and choose a partition key that you know will not exceed this 10 GB limit. You will need to transfer data from your old to new collection as well.

You may find this post useful in choosing a partition key for your collection: https://learn.microsoft.com/en-us/azure/cosmos-db/partition-data#design-for-partitioning.

Furthermore, per this blog post, the minimum RU/s for an unlimited collection is now 1000 instead of 2500.

Gaurav Mantri
  • 128,066
  • 12
  • 206
  • 241
  • 1
    I DM'ed @AzureCosmosDB with a similar question. They referred me to https://docs.microsoft.com/en-us/azure/cosmos-db/partition-data. The relevant quote is "When a physical partition p reaches its storage limit, Azure Cosmos DB seamlessly splits p into two new partitions, p1 and p2. It distributes values corresponding to roughly half the keys to each of the partitions. This split operation is invisible to your application." I believe this is only applicable for Unlimited Collections. I am guessing Sarva created a Fixed collection and is bumping against the hard limit for the single partition. – Rob Reagan Dec 30 '17 at 14:11
  • 1
    @RobReagan...Interesting! I didn't know that. Thanks for sharing. Now I am curious as to why Cosmos DB team is even mentioning this 10GB limit when they can split the data in the background. I will delete my answer once Sarva confirms that the collection is Fixed collection. – Gaurav Mantri Dec 30 '17 at 14:22
  • I feel that the docs are confusing. I *think* that the partition key in the Fixed Collection is to provide a migration path to an Unlimited Collection. I seem to recall reading that somewhere, but am not 100% sure. – Rob Reagan Dec 30 '17 at 14:24
  • @RobReagan Please see Rajesh Nagpal's response here: https://stackoverflow.com/questions/46017040/purpose-of-a-partition-key-for-a-cosmos-db-fixed-10gb-collection/46136979#46136979. – Gaurav Mantri Dec 30 '17 at 14:27
  • Haha! Well, now I know why that sounded familiar. It was my own question. :-) But what wasn't mentioned is *how* to migrate from a fixed collection with a partition key to an unlimited, which is probably relevant for Sarva's situation. Sounds like we should experiment. – Rob Reagan Dec 30 '17 at 14:30
  • I agree with @RobReagan I'm not very sure whether I have created unlimited or fixed. Please advise how this should be resolved. Is it possible to make it work without migrating the data to another collection? – Sarva Dec 30 '17 at 14:45
  • @Sarva, to check, log into the Portal, navigate to your collection, and choose "Scale & Settings". If your Storage Capacity says "Fixed (10GB)", it's fixed. You can also look at the Throughput range. If it says "400 - 10,000RU/s", it's fixed. – Rob Reagan Dec 30 '17 at 14:48
  • I have posted a question concerning migration at https://stackoverflow.com/questions/48035031/migrating-a-cosmos-db-fixed-collection-with-partition-key-to-an-unlimited-collec. Let's see what that turns up. – Rob Reagan Dec 30 '17 at 14:56
  • @RobReagan I have checked everything. The storage capacity = Unlimited and Throughput = 2500. The data size = 11.67 GB and index size 885.5 GB. – Sarva Dec 30 '17 at 15:38
  • @RobReagan We are maintaing applications log in the collections. TraceType is a partition key. Trace types are debug, exception, trace etc. We are able to store exceptions and traces in the collection but not debug. It seems "debug" partition is full. – Sarva Dec 30 '17 at 16:33
  • @Sarva, I've emailed your problem and a link to this post to a gentleman who is active on StackOverflow and who works on the Cosmos DB engineering team at Microsoft. I've also posted a follow-up question to reconcile the behavior you're experiencing with the aforementioned docs on the docs page itself. I am curious as to the answer. – Rob Reagan Dec 30 '17 at 17:24
  • @Sarva You need a more fine-grained partition key. Even though you may be on the Unlimited plan, you don't have enough cardinality in your partition key choice. Instead of TraceType, perhaps something like Date could serve as a better partition key. Or perhaps a combination of both TraceType and Date. Example, you could have a string field that represents this partitionKey and it could be something with a value of "Debug_2018-05-27" and "Exception_2018-05-27". – Tim P. May 28 '18 at 03:56
  • @TimP. Thanks for the response. – Sarva May 28 '18 at 07:58
  • How I can get a current size (used) for each partition key for avoiding this issue? Anh How I can get the maximum size for each partition key? (because maybe azure will change the maximum of each partition key in the future?). A both table API and documentDB (sql API) – Duc Nguyen Mar 15 '19 at 10:06
  • 1
    @DucNguyen Instead of asking questions in comments or as a separate answer, please ask a new question. – Gaurav Mantri Mar 15 '19 at 10:30
  • 1
    This limit has been recently raised to 20 GB. Reference: https://learn.microsoft.com/en-us/azure/cosmos-db/concepts-limits – juunas May 11 '20 at 13:24
  • @juunas...for you I will update this 2.5 year old post :). – Gaurav Mantri May 11 '20 at 13:26
1

Data in CosmosDB is stored in collections which are partitioned using a partition key that you choose. Each individual partition is limited to 10GB of data.

Unlimited collections are unlimited in the amount of partitions, but a fixed collection limits you to a single partition. That's the only difference. That's why a fixed collection doesn't need a partition key set (because everything goes to the single partition) and why the limits for a fixed collection and a partition are the same size of 10GB.

How these partitions are actually stored on the CosmosDB servers is infrastructure that you do not have control over, and it's automatically managed for replication and performance. You can store as much data as you want in a collection as long as you can split it amongst enough partitions. It is better to have more partitions than fewer and even picking the ID field (to put a single record in every partition) will work fine. CosmosDB can automatically group partitions together to fill a server but it cannot split a partition apart, so be wary of that in your design.

Mani Gandham
  • 7,688
  • 1
  • 51
  • 60
  • 1
    This limit has been recently raised to 20 GB. Reference: https://learn.microsoft.com/en-us/azure/cosmos-db/concepts-limits – juunas May 11 '20 at 13:24