Nick

My feedback

  1. 92 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  Azure Resource Manager  ·  Flag idea as inappropriate…  ·  Admin →
    Nick supported this idea  · 
  2. 50 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Azure Cosmos DB » Other  ·  Flag idea as inappropriate…  ·  Admin →

    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.

    Nick supported this idea  · 
  3. 2 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Azure Cosmos DB » Other  ·  Flag idea as inappropriate…  ·  Admin →

    @Ian.

    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.

    @Nick.

    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  · 

    Scenario 1:

    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).

    Scenario 2:

    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"
    https://docs.microsoft.com/en-us/azure/cosmos-db/tutorial-global-distribution-sql-api#connecting-to-a-preferred-region-using-the-sql-api

    Nick supported this idea  · 
  4. 24 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Stream Analytics  ·  Flag idea as inappropriate…  ·  Admin →

    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.

    Nick supported this idea  · 
  5. 160 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under 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.

    Nick supported this idea  · 
  6. 23 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Azure Cosmos DB » SQL API  ·  Flag idea as inappropriate…  ·  Admin →
    Nick supported this idea  · 
  7. 217 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  Azure Cosmos DB » Change Feed  ·  Flag idea as inappropriate…  ·  Admin →
    Nick supported this idea  · 
  8. 54 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  Azure Cosmos DB » Change Feed  ·  Flag idea as inappropriate…  ·  Admin →
    Nick supported this idea  · 
  9. 136 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    9 comments  ·  Azure Cosmos DB » Other  ·  Flag idea as inappropriate…  ·  Admin →
    Nick supported this idea  · 

Feedback and Knowledge Base