Autoscale Throughput (RU/s)
Depending on the average amount of incomming requests/ required RU's, (or other parameters,)
I would like to autoscale the througput(RU/s) of a collection.
We have now released autoscale for general availability.
Thank you everyone for your comments and votes. We are very excited to release this feature for all of you.
Felix Schröter commented
A similar approach to DynamoDB's auto scaling would be nice.
So we can define minimum and maximum throughput and all the scaling happens automatically.
then you need to review your plans , this has got to be the most important feature for us... There are no reason whatsoever you not supporting this other than to milk us for more money... which is making you look very bad... remember Micro$oft?
If we can control auto scaling in our code (ontrottle() -> scale 1000) -> retry) and this is instant... You can also do it automagically. <- not a typo.
This just becomes a code maintenance **** when using 100s of functions where this needs to be included...
the RU/s needs to elastically scale. Your engine already supports "live" RU scaling through the portal with instant no impact scaling.
It needs to be we set the MAX RU/s we want to support and we get charged for actual RU/s usage. There is no other way this will work.
We use functions a LOT and they scale elastically based on required throughput. If they scale we need our DB to also scale together with the functions. Right now we have the portal open and monitor throughput and adjust manually each 5 minutes or so (ewwww). This could also be done inside each function to check for throttled requests and scale but that quickly becomes cluncky as ****.
I would also like autoscaled RU/s feature for collections. It's very clumsy having to manage our own throughput. And I can't even find any way to find current RU/s usage for a collection so I can make my own autoscale service.
I am kind of confused about the Autoscale throughput. Is it supported or not? Since it isn't present in Azure Portal if it is supported, can I configure it manually via Nodejs SDK?
Leow Kah Man commented
If you are going to remove the RU/minute option, why don't you at least indicate it in the doco instead of deleting the information like it never existed?
Although the option is disappeared in Azure Portal, I noticed that the (.NET) SDK still supports RU/minute (see OfferIsRUPerMinuteThroughputEnabled)
Again; what is the status regarding RU/minute ?!?
(Is it deprecated and going to be removed or replaced (with something awesome?) ?!?
@Arnaud Comet; I no longer have the scaling option RU/m available in any of my collections.
First the option was only unavailable for DocumentDB collection under 'Enterprise MSDN Dev/Test' subscriptions, but now also for our 'Enterprise Agreement' subscription.
Also, in de documentation I no longer see the option RU/m.
I would like to known the status and, if available, other(/better?) solutions to re-complete for this idea.
It looks like Request Per Minute is no longer available.
In App Service Plan it is possible to configure auto scaling. I would like the same capability in CosmosDB. I.e. I could set a lower and upper RU/s and if throttling was about to occur, Cosmos DB could instead increase RU/s until the upper limit was reached or throughput was met. And Cosmos would also automatically lower RU/s if traffic is low.
Takayuki Mitsui commented
Please provide auto scale option in DocumentDB for scaling down and scale up of collection based on RU running.
Hey, TJGalama, I don't think this idea should be marked complete. The RU/minute feature is kinda nice, but it's just another knob for us to turn in our tuning. The bad part is though, I STILL have to try to guess my traffic patterns and pre-configure things beforehand for all of my apps across all of my environments. The request here is that we don't want to think about stuff like this in the cloud.
Here is the analagy for you: I don't want to rent a specific number of servers, I want them to auto-scale based on web traffic. In the same fashion, I don't want to rent a specific database throughput size, I want it to auto-scale with my DB usage.
Ideally, we shouldn't even need to think about auto-scaling, you should just charge us per RU consumed, done and end of story. If I use a lot, I pay a lot - if I use a little, I pay a little, but I NEVER want to overpay. By pre-provisioning, I'm guaranteed to be overpaying.
Can you please leave this issue open? We want RU auto-scaling, not more knobs to turn to configure RU allotment.
Gary Strange commented
This maybe a duplicate of the planned feature: Autoscale Throughput (UR/s)
This feature would go very nicely with Azure Functions.
This is a great idea! Azure team, I can tell you what the BEST customer experience would be. Ideally, I should never have to do capacity-planning up front, I just want pay-as-I-go. Now, I understand that to meet your SLAs it's much easier if we (the customer) tell you how much capacity we need up front. But, the best experience would be that I would just pay some fraction of a penny per RU used. This would be true auto-scaling at the database layer. I don't want to have to come in and dial up my RU capacity for Mon-Fri, and then dial it back down on Sat-Sun. That means I'm guaranteed to be overpaying for the capacity, because I always need to over-provision to make sure I don't get throttled.
So, your 'bursting' idea would be helpful, but it's still not the ideal customer experience. We just want to pay per RU. That is the most fair way for us to pay, as it is truly pay-as-you-go with no over-spending or over-provisioning. I understand that is technically difficult for you to implement, but that's ideally what we want.
There should be a plan like 400 RU reserved with bursts up to 1000 RU (if resources are available at the time) We should be charged for the bursts but then auto scales back down. Usually bursts are only needed for a couple minutes.
Yeah I usually have 0-200 RU's but then have temporary spikes up to 500 RU's So at my 400RU account it usually works but sometimes gets throttled. Would be nice to have Roll Over RU's like cell phone data.
Tom Kerkhove commented
It would be nice to have the capability to opt-in for out-of-the-box scaling up when you're reaching your RU limits
You pay only for what you use. Isn´t that the main selling point of every cloud platform?? I think this is very important!