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?
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).
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.
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:
Strong / Single Master = 0 minute;
Session / Multi-master < 15 minute;
Consistent Prefix / Multi-master < 15 minute;
Eventual / Multi-master < 15 minute;
Recovery Time Objective (RTO) se comportă similar, oferind un SLA de maximum 7 zile, cu:
Session / Multi-master = 0 minute;
Consistent Prefix / Multi-master = 0 minute;
Eventual / Multi-master = 0 minute;
Strong / Single master < 15 minute;
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ță.
de Marin Vlada
