2

Multi-Master Database with single region: SDK reports ~10 RU to perform a write operation
Multi-Master Database with 5 regions:: SDK reports ~46.86 RU for the same operation (~5x to incorporate replication to all regions. Makes sense)

If you have a collection provisioned at 10k RU, does cosmos provision 10k RU for every region? The microsoft docs would suggest so but then the SDK reports all region cost when writing to the local region as above which seems a bit odd / confusing? Additionally, I don't see any other write activity in the other regions in order to replicate writes into those regions.

enter image description here

Question: Do you pay the cost of 46RU in your local write region or is the cost reported by the SDK essentially divided by the number of regions you have with each region paying the cost? So in the above scenario with five regions does that write operation cost 10RU in each region or a once off charge of ~47 RU in the local write region?

Joshua Hayes
  • 1,938
  • 2
  • 21
  • 39

1 Answers1

1

Each region gets the specified allocation of RU, so if you create a 10K RU collection, and have 5 regions in your multi-master environment, you will have 10K x 5 = 50K RU available to you (and paying for 50K RU).

Each operation has its own RU charge, so if a write takes place in all 5 regions, then you are going to consume the RU in each region (it does not result in 5x the RU cost in a single region). The upside is that writes in one region don't affect available RU in another region. However, you will be paying for RU capacity in each region (effectively a multiplier, for the number of regions you specify).

David Makogon
  • 69,407
  • 21
  • 141
  • 189
  • Just to clarify, if a multi-master database single region cost is ~10RU and the same operation executed on a multi-master with 5 regions is reported by the SDK has ~50RU, in the latter environment that 50RU is actually spread across the five regions participating in the replication? So even though the SDK reports 50RU charge, the cost per region is ~10RU (the same as if you were writing to a single region database)? – Joshua Hayes Dec 26 '18 at 01:05
  • Correct, in that the same operation needs to occur in each region. I can't speak to how the SDK reports RU cost when using a multi-write-region configuration, but you absolutely have to pay for RU allocation per region (as well as storage per region). Also, one thing different about multi-write-region vs geo-replication (single write region, multiple read regions): the RU cost is higher with multi-write-region config (this is all spelled out on the [pricing page](https://azure.microsoft.com/en-us/pricing/details/cosmos-db/), with examples given in the FAQ). – David Makogon Dec 26 '18 at 04:40
  • 1
    fyi I tested with multiple write regions, via .net core, and the RU cost goes up with each write region I add; however, when using single-write multi-region, the RU cost doesn't appear to increase via return value of each call, though I know that I'm still consuming RU in each additional read region. This is why I said I can't speak definitively to the total RU cost returned by the SDK (or Cosmos DB, via the SDK or direct REST calls). – David Makogon Dec 26 '18 at 04:42
  • Yep. All of that makes sense and I have been through the Microsoft docs and pricing page several times. I'm still having trouble working out whether the cost reported by the SDK, in a multi-master-region environment is incurred in each region or divided amongst them. Looking at activity in the portal, the portal does not make this clear when you only see activity only in the local region. Your answer was quite clear and consise though and answered part of my question so I am going to accept that. Thanks. – Joshua Hayes Dec 26 '18 at 05:25
  • Thank you. That is what I found, when adding additional write regions the reported cost from the SDK increased accordingly. As above though, it's not clear to me how that increased RU cost is incurred though when the collection is already provisioned across all regions. – Joshua Hayes Dec 26 '18 at 05:27