ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 144
Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 95
Abonament PDF

Cum este afectată latența de nivele de consistență Azure CosmosDB ?

Radu Vunvulea
Solution Architect
@iQuest



PROGRAMARE


Azure Cosmos DB are cinci nivele diferite de consistență (Strong / Bounded Stateless / Session / Consistent Prefix / Eventual). Fiecare nivel de consistență poate afecta, la nivel de stocare, latența operațiunilor pe care le efectuăm.

Vom încerca să răspundem la următoarea întrebare: Care este impactul diferitelor nivele de consistență asupra latenței? 

Latența - aspecte generale

SLA-urile curente ne oferă garanția că operațiunile READ (citire) și WRITE (scriere) sunt în 99% din cazuri sub 10 ms. Latența medie cu care se aduce momentan conținutul din Azure Cosmos DB este sub 4 ms în 50% din cazuri.
Operațiunile de scriere sunt puțin mai lente, 5ms în 50% dintre cazuri. Acest lucru este valaibil doar pentru Bounded Stateless / Session / Consistent Prefix și Eventual.

Pentru nivelul de consistență Strong și baze de date din regiuni multiple, latența este mai mare, dar acest lucru este de așteptat, date fiind cerințele ce țin de replicare (copiere). De exemplu, dacă avem nivel de consistență Strong pe o bază de date care este replicată (copiată) în două regiuni diferite, latența ar fi egală cu timpul necesar pentru a efectua două ture complete între regiunile cu cel mai lent transfer plus 10ms latență în 99% dintre cazuri. Cele 10ms suplimentare au ca sursă operația de citire (confirmare) necesară pentru a ne asigura că operația a fost realizată cu succes.
Există încă un aspect ce trebuie avut în vedere:

Așadar este imposibil de calculat și de avut SLA pentru nivelul de consistență Strong. În cele mai multe cazuri, latența va fi egală cu:

Notă: Monitorizarea procesului de replicare  - Microsoft Azure monitorizează latența replicărilor. Informația este disponibilă pe Azure Portal (Azure Portal / Metrics/ Consistency Level).

Testul real

Luați în calcul faptul că de fiecare dată când rulați același test sau un test diferit, rezultatele vor fi diferite. Mai multe aspecte pot afecta rezultatele, inclusiv mașina de test.

Am rulat toate testele de pe o mașină Standard_D5_v2 VM, cu 16vCores și 56GB memorie. Fiecare test a rulat de 500.000 de ori și s-a bazat pe conceptele și metodologia din articolul Practical Large-Scale Latency Estimation, elemente pe care le-am folosit și în trecut pentru a efectua măsurători. A existat un timp de încălzire, iar din această valoare de 4%, am exclus latențele cu valori minime și maxime. Dimensiunea setului inițial a fost de 100.000 de documente cu o dimensiune medie de 50KB per document.

Luați în calcul faptul că am preluat aceste rezultate din sandboxul meu și că acestea nu se aplică altor situații (sau cazuri generale).

Rezultatele obținute sunt foarte bune și au un grad ridicat de încredere în ceea ce privește Azure Cosmos DB.

Ce se întâmplă cu RPO și RTO?

Să luăm în calcul Recovery Point Objective (RPO). SLA-ul curent este interesant, oferind o valoare maximă de 240 de minute pentru orice nivel de consistență sau număr de copii. 

RPO-urile curente sunt:

Recovery Time Objective (RTO) se comportă similar, oferind un SLA de maximum 7 zile, cu:

Concluzie

Nivelul de performață a sistemului poate fi afectat direct de către gradul de consistență pe care dorim să o folosim. Fiecare nivel de consistență va afecta în consecință performanța și costurile. Pentru cele mai multe cazuri nivelul Session de consistență este o soluție bună între numărul de utilizatori activi și performanță.

LANSAREA NUMĂRULUI 144

Modern Agile

joi, 20 iunie, ora 18:00

sediul msg systems Romania

Facebook Meetup StreamEvent YouTube

NUMĂRUL 143 - Software Craftsmanship

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Colors in projects