Ian Bennett
My feedback
-
1 voteIan Bennett
shared this idea
·
-
2 votesIan Bennett
shared this idea
·
-
1 voteIan Bennett
shared this idea
·
-
3,752 votesIan Bennett
supported this idea
·
-
1 voteIan Bennett
shared this idea
·
-
326 votes
This is currently on our road map. Stay tuned for this in an upcoming release.
Thanks.
Ian Bennett
supported this idea
·
-
2 votes
If all of your client connections are to the region your application is deployed in then your application will always use the Cosmos DB replica in the closest region which is the same region you are deployed in.
If you are replicating to a second region the way you would load balance this is to deploy your application into that same region and configure it to point to it, then use Traffic Manager in front of your application to load balance client requests to the closest region that hosts your application.
If this is not what you are asking or suggesting please feel free to provide more information and we can assist.
Thanks.
Ian Bennett
commented
The replica is setup more for DR purposes but there is no option to run the secondary at reduced RUs so that is potentially a lot of wasted resource and money. If I am using something like Power BI Service then I don't get a lot of say in where the application runs from. You are assuming a 3 Tier Architecture but Cosmos is not just being used for apps and websites. Data Analytics applications are often 2 Tier and more taxing on the database.
Ian Bennett
shared this idea
·
-
13 votes
This capability is not on our road map today but we do provide query metrics using our SDK’s. You can read more about what we provide here, https://docs.microsoft.com/azure/cosmos-db/sql-api-sql-query-metrics#query-execution-metrics.
Thank you for your suggestion.
Ian Bennett
commented
By "monitor" I mean individual queries and the focus on this suggestion was actually meant to be on the "killing" part. Its not hard to end up with rogue queries chewing up the RUs.
Ian Bennett
shared this idea
·
-
1 voteIan Bennett
shared this idea
·
-
8 votesIan Bennett
commented
A trigger based on "Number of requests exceeded capacity" metric would be useful too. Logic flow might look something like if number of requests exceeds capacity > n then increase RU throughput by 10% with a maximum of x RUs.
Ian Bennett
shared this idea
·
-
1 voteIan Bennett
commented
Occurs when timestamp is a string but not when a number. Range indexing is used on string by default. Otherwise, performance of range query on timestamp is similar for both number and string formats.
Ian Bennett
supported this idea
·
Ian Bennett
shared this idea
·
-
28 votesIan Bennett
commented
My partition keys are GUIDs in order to evenly distribute eclectic data over the partitions. I therefore do not know the keys upfront and "DISTINCT partitionKey" is of no use.
Ian Bennett
commented
Also, it looks like the node.js SDK does not support passing of partition keys when executing a stored procedure.
Ian Bennett
shared this idea
·
-
0 votes
We are investigating this now. Will report back.
Thank you for reporting.
Ian Bennett
shared this idea
·
-
1 voteIan Bennett
shared this idea
·
-
1,011 votes
Thank you for all the feedback for the preview of RU/m. We are currently reviewing feedback to drive further improvements. Please stay tuned. For any questions, please reach out to us at AskCosmosDB@microsoft.com
Ian Bennett
commented
For partitioned collections it would be good if autoscale would work on a per partition basis to keep costs down. RU allocation across every partition can be inefficient as in the following examples.
1. RU allocation applies to all replicas. Using node.js SDK, it is not possible to direct queries to secondary replicas so that RU goes largely unused.
2. In some use cases it can be better for performance to only use 1 or 2 partitions at a time for read/writes but over time data is spread across all partitions. In this case the RU for all partitions not being actively used at the time are largely unused.
Ian Bennett
commented
My suggestions are, in order of preference:
1. Allow setting of a max RU/s limit and auto scale between lowest possible and up to that limit
2. Bring back RU/m.
3. Allow scheduling of RU/s settings from the Portal (I know this can already be done in a convoluted fashion with command line).Ian Bennett
supported this idea
·
-
108 votesIan Bennett
supported this idea
·
-
4 votesIan Bennett
shared this idea
·
-
10 votes
We’ve made progress on this scenario/pattern implementing message routing in the IoT Hub service.
You can today set rules (called routes) based on messages content or headers and have them sent directly to “custom endpoints” (today we support Event Hub, Service Bus Queues and Topics, Blob Storage). Learn more here: https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-endpoints#custom-endpointsWe are considering other custom endpoint types. Your feedback is welcome here.
Ian Bennett
supported this idea
·
-
6 votes
This is a great idea. Please include a list of the top most generic tasks you would like to see.
Ian Bennett
commented
Cosmos DB - scale up/down RUs.
-
32 votesIan Bennett
commented
Further to this, the UTC settings should apply to Advanced Schedule as well. Regardless, it would be good if the timezone was shown in Advanced Schedule to avoid confusion.
Sorry, I actually gave up on using MSI.