Thank you for taking the time to vote on this request. Work on this has commenced. We will email you once it is completed.
If you are interested in participating in the preview please email back.
Hi Magnus. This is currently unplanned by us for our road map. Some context and feedback for you on this.
First, to do the replication itself to the secondary region you need RU/s sufficient to support the request rates for the primary region itself. Replication and writing to the secondary region itself is not free so there needs to be sufficient throughput provisioned to do that.
Second, for the secondary region to be able to function as the primary should a fail over occur, the replica region itself needs sufficient throughput to function as the primary.
Thanks again for your suggestion. Will mark as unplanned for now in case circumstances ever do change.
With regards to secondary regions having different RU/s we do not have this on our road map at this time. There is another User Voice items which have this suggestion, Please feel free to vote that item up.
For scenario 1. Same answer.
For scenario 2. Typically, just putting the front-end closer to users is not something we see help with application latency where they are backed by a database as the app still needs to call the database which is still separated by some distance.
With regards to knowing which region to point to I would suggest conducting tests to see which regions provide the best latency and include this as the preferred regions for each regional deployment.
Thank you both for your suggestion and comments.Nick commented
East US and West US both have Cosmos DB and my application deployed. In this case, it seems sensible that the application deployment to East US should have the following Preferred Location list: East US, West US. The deployment to West US would have the reverse. But what about if 95% of my user base routes to the West US application via Traffic Manager, based on closest region? This gives minimal latency from user to application (yay, Traffic Manager win!), but then causes load distribution problems on the Cosmos DB and my RUs are not efficiently utilized because East US will need to have enough provisioned to serve West US (side note, there is another request for provisioning region-specific RUs that can also mitigate this problem).
Lets say I have the following Cosmos regions:
East US, West US, South Central US
And I have my application deployed across these regions:
East US, West US, South East Asia, Japan East, Brazil South, North Europe
Lets say I have good reasons not to replicate the data outside US, but have to reach a global user base so there is value in getting the applications closer to the user.
In this case, the deployments in the regions outside the US have to essentially be hard-coded (or at least statically configured) to specify the Preferred Locations of Cosmos DB replicas, but how would I know the best sequence of regions to specify from any given region (without guess and check, and ongoing validation)?
In general, I fully agree that the service should provide a mechanism to decide which replica should serve a read request based on availability, geo proximity, load, etc. without mandating the client to do so. The client should certainly be able to explicitly override, but if not specified the service should have the capability without the current behavior of "If the PreferredLocations property is not set, all requests will be served from the current write region"
24 votesunplanned · AdminAzure Stream Analytics Team on UserVoice (Product Manager, Microsoft Azure) responded
We are exploring the possibility of supporting CosmosDB change feed as ingress to Stream Analytics which will solve this scenario. For reference data, we already provide a mechanism to refresh reference data in Azure Blob storage using Azure Data Factory. More details about this here: https://docs.microsoft.com/en-us/azure/stream-analytics/stream-analytics-use-reference-data
We are listening and committed to making Stream Analytics even better! Keep your feedback coming.
160 votesunder review · 10 comments · Stream Analytics » Inputs and Outputs · Flag idea as inappropriate… · Admin →Nick commented
Cosmos DB should be a source of reference data, but the Cosmos DB Change Feed should be valid input to a Stream Analytics job as well. Solve different use cases, both equally necessary.
Work for this feature is currently on our backlog and not in our current development cycle plan. We will continue to revisit this item in upcoming cycles and will update here if this item moves in plan.
Thank you for your suggestion and votes.
This is on our long term roadmap and are still evaluating this but no ETA. Will update as this changes.
Thank you for your suggestion.
This is on our roadmap and we are currently working on this. Will update when this becomes available.
Thank you for your suggestion.
We have reviewed this and have elected to not include this on our road map for the time being. We may revisit this in the future so will leave as unplanned rather than declined or closed.
Thanks for your suggestion and comments.