I have 4 collections in a CosmosDB and I have scaled down to 400RUs 3 of them but the 4th I cannot scale down. I can put 400RUs in the portal but the Save button wont activate. Why? How can I scale down my collection? The minimum it says it is 1000 RUs.
I totally agree with what #David Makogon says. Combine with the guidance on the portal when we create collections, we can't set RUs less than 1000 if we create unlimited partitioned collection.
I tested some different situations.
Test1:
I created unlimited partitioned collection successfully with 1000 RUs. Then I found the range of throughout is 400-10000 RUs.
I scaled down the throughout to 400 RUs and it can be saved.Also, the stroage capacity changed to Fixed with it as same as you. Fully demonstrate the scalability of Cosmos db.
Test 2:
I noticed that the range of throughout is 1000-50000 RUs in your screenshot. So I created a new unlimited partitioned collection successfully with 1100 RUs. And it can't scaled down to 400 later.
I think that's the reason though I can't find any official explanations related to this. So you could refer to my test conclusion that if you set throughout larger than 1000 RUs when you create an unlimited collection, then you can't scale down it less than 1000 RUs later.
Hope it helps you.
You're trying to scale down a partitioned collection (the giveaway is the presence of a partition key), which starts at 1000 RU.
Only single-partition (10GB) collections go down to 400 RU.
Related
I have migrated all my databases to CosmosDB with Mongo API by removing indices. After the migration, I started creating indices manually on CosmosDB. I have a collection called to order. It has 7 Million documents each document is nearly 1 KB in size. But as I update the index it is taking a lot of time. I am checking the index update status. It is been 30 minutes still the update is only 40 % complete. is this index update is a lot of RU consuming operation.? I know we have a limitation of 5000 RU/s per container. So is this slowness is because of that. If someone knows the answer to this please help me. And also, will the Azure cost me for the RU's that I consume during an index update. I have read somewhere that it won't.
I'm trying to figure out why my CreateItem<T> returns a request charge of 7.05 RU for inserting a simple object with 5 properties, less then 1KB including the id and partition key. Its just a default container, with default indexing etc.
The documentation says it should be 5 RU. I've tried to use the ItemRequestOption to disable returning the object, disable indexing for that item etc. but it stays at 7.05 RU. I've also tried changing the consistency level of the account but nothing changes.
A ReadItem on id and partition key returns with a RU charge of 1.0 as expected and a RU of 2.9 if run as a query.
I'm a little annoyed at the 7.05 RU cost for the CreateItem since its a 41% increase in RU cost over the 5 RUs. Enabling TTL jumped the RU cost to 7.65.
What is the best way to diagnose these kind of issues? I've tried looking at the response diagnostics but its not really helpful.
RU consumption on write operations will be heavily impacted by your indexing policy.
By default CosmosDB container will have indexing enabled for the whole document (each property). If you replace it with specific paths which are used heavily in queries, it can significantly improve performance of write operations as well as reduce consumption costs.
Also please note that there is no guarantee in RU consumption per document in query: documentation. It will vary based on index, partition keys, cardinality of partitions, geo-replication, "fan-out" during execution etc.
We are planning in writing 10000 JSON Documents to Azure Cosmos DB (MongoDB), Does the Throughput Units matter, if so, can we increase for the batch load and set it back to low number
Yes you can do that. The lowest the RUs can be is 400. Scale up before you're about to do your insert and then turn it down again. As always, that part can be automated if you know when the documents are going to be inserted.
Check out the DocumentClient documentation and more specifically ReplaceOfferAsync.
You can scale the RU/sec allocation up or down at any time. You'll want to look at your insertion cost (RU cost is returned in a header) for a typical document, to get an idea of how many documents you might be able to write, per second, before getting throttled.
Also keep in mind: if you scale your RU out beyond what an underlying physical partition can provide, Cosmos DB will scale out your collection to have additional physical partitions. This means you might not be able to scale your RU back down to the bare minimum later (though you will be able to scale down).
At first, I have created DocumentDB Collection with 2000 as Throughput. after I have realized that it is too high, I tried to reduce by clicking (-) button. It got reduce till 1000 after that it doesn't work. I want to set as 400.
Unfortunately it is not possible to do so considering your collection is of unlimited size. Minimum throughput for such collection is 1000 RU/s (earlier it was 2500 RU/s).
If you want to have a collection with 400 RU/s, please create a new collection with fixed storage capacity (currently 10GB) and migrate the data from your existing collection to this new collection.
There were some updates to the performance level of Cosmos DB recently. The previous S1, S2, S3 performance levels have been retired. Now there are only two types of containers, fixed and unlimited. As Gaurav mentioned, the RU/s range for fixed is from 400 - 10,000, and for unlimited is from 1,000 - 100,000. And unlimited must have a partition key, while fixed doesn't have to.
More details can be found in this newly updated document: Partition and scale in Azure Cosmos DB. According to this document, my suggestions would be, even if you go and create a fixed container, you should still give it 1,000 RU/s and a partition key so you don't have to do migration in the future in case your data or load grows beyond the capacity of the fixed container.
I'm looking into moving to the new partitioned collections for DocumentDB and have a few questions that the documentation and pricing calculator seems to be a little unclear on.
PRICING:
In the below scenario my partitioned collection will be charged $30.02/mo at 1GB of data with a constant hourly RU use of 500:
So does this mean if my users only hit the data for an average of 500 RU's for about 12 hours per day which means that HALF the time my collection goes UNUSED, but is still RUNNING and AVAILABLE (not shut down) the price goes down to $15.13/mo as the calculator indicates here:
Or will I be billed the full $30.01/mo since my collection was up and running?
I get confused when I go to the portal and see an estimate for $606/mo with no details behind it when I attempt to spin up the lowest options on a partition collection:
Is the portal just indicating the MAXIMUM that I COULD be billed that month if I use all my allotted 10,100 RU's a second every second of the hour for 744 consecutive hours?
If billing is based on hourly use and the average RU's used goes down to 100 on some of the hours used in the second scenario does the cost go down even further? Does Azure billing for partitioned collections fluctuates based on hourly usage and not total up time like the existing S1/S2/S3 tiers?
If so then how does the system determine what is billed for that hour? If most of the hour the RU's used are 100/sec but for a few seconds that hour it spikes to 1,000 does it average out by the seconds across that entire hour and only charge me for something like 200-300 RU's for that hour or will I be billed for the highest RU's used that hour?
PERFORMANCE:
Will I see a performance hit by moving to this scenario since my data will be on separate partitions and require partition id/key to access? If so what can I expect, or will it be so minimal that it would be undetected by my users?
RETRIES & FAULT HANDLING:
I'm assuming the TransientFaultHandling Nuget package I use in my current scenario will still work on the new scenario, but may not be used as much since my RU capacity is much larger, or do I need to rethink how I handle requests that go over the RU cap?
So they way that pricing works for an Azure documentDB is that you pay to reserve a certain amount of data storage size (in GB's) and/or throughput (in Request units (RU)). These charges are charged per hour that the reserve is in place (does not require usage). Additionally, just having a Document Account active is deemed to be an active S1 subscription, until a documentDB gets created then the pricing of your db takes over. There are two options available:
Option 1 (Original Pricing)
You can a choose between S1, S2 or S3. Each offering the same 10GB of storage but varying in throughput 250RU/1000RU/2500RU.
Option 2 (User-defined performance)
This is the new pricing structure which better decouples size and throughout. This option additionally provides for partitioning. Note that with user defined performance you are charge per GB of data storage used (Pay as you go storage).
With user-defined performance levels, storage is metered based on
consumption, but with pre-defined performance levels, 10 GB of storage
is reserved at the time of collection creation.
Single Partition Collection
The minimum is set at 400RU and 1GB of data storage.
The maximum is set at 10,000RU and 250GB of data storage.
Partitioned Collections
The minimum is set at 10,000RU and 1GB of data storage.
The maximum is set at 250,000RU and 250GB of data storage (EDIT can request greater).
So at a minimum you will be paying the cost per hour related to the option you selected. The only way to not pay for an hour would be to delete the db and the account, unfortunately.
Cost of Varying RU
In terms of varying your RU within the time frame of 1 hours, you are charged for that hour at the cost of the peak reserve RU you requested. So if you were at 400RU and you up it to 1000RU for 1sec you will be charge at the 1000RU rate for that hour. Even if for the other 59minutes 59secounds you set it back to 400RU.
Will I see a performance hit by moving to this scenario since my data will be on separate partitions and require partition id/key to access?
One the topic of perfromance hit there's a few things to think about, but in general no.
If you have a sane partition key with enough values you should not see a performance penalty. This means that you need to partition data so that you have the partition key available when querying and you need to keep the data you want from a query in the same partition by using the same partiton key.
If you do queries without partitionkey, you will see a sever penalty, as the query is parsed and executed per partition.
One thing to keep in mind when selecting a partition key is the limits for each partition, which are 10GB and 10K RU. This means that you want an even distributions over the partitions in order to avoid a "hot" partition which means that even if you scale to more than enough RU in total, you may recieve 429 for a specific partition.