We’re excited to announce that we are making this a lot easier with our preview of Autopilot. With Autopilot, Azure Cosmos DB will automatically manage and scale the RU/s of your containers based on the usage. This eliminates the need for custom scripting to change RU/s and makes it easier to handle bursty, unpredictable workloads.
You can try out Autopilot in your Cosmos accounts by going to the Azure Portal and enabling the feature in the “Preview Features” blade.
Any updates, Azure team? Can you give us any hints? Is this coming in 2019?
Any updates here?
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.
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.
Reopening this user voice item as our support for Skip/Take (Offset/Limit) was only limited to single partition queries.
The newly released .NET SDK v3 now includes support for x-partition queries using Offset/Limit. You can learn more about v3 SDK and try it and provide feedback on our github repo here.
We will also be back-porting this functionality to our .NET v2 SDK. This work will begin shortly and we anticipate it to be released in September.
Once that is released we will mark this feature as complete.
Thank you for your patience and votes.
Question - is this an "efficient" implementation? To be specific, is it just as efficient in terms of latency and RUs consumed to read from offset 5 than it is to read from offset 50,000? Did you guys implement this in a way that under the covers, on the server side, you just page through results in a tight loop until you've burned through N results, and then return the next page of items? Or did you actually build an index for this so that it's efficient to immediately jump to the 50,000th item and read the next page of results?
Looking forward to your answer, thanks.
Work on this feature has started. Will update here when this becomes generally available.
Thank you for your suggestion and votes.
Thank you for your feedback. This is one of our top voted items, so this is something we would really like to do. We’re considering this for a future release of Azure Search.
Azure Search Product Team
In addition, we need to be able to change whether an existing property is "Facetable" or "Searchable", and we need to be able to add Suggesters and Custom Analyzers to existing fields in an index.
Without this capability, we can't use any new Azure Search features you release. Requiring us to create a new Search Index every time you release a feature is analogous to requiring users to delete their production database and create a new one every time a database feature is added.
No new Azure Search capabilities can be used by existing production customers until you enable this feature. This is critical!