{"id":37585,"date":"2019-10-31T22:18:27","date_gmt":"2019-10-31T19:18:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-zaglyanut-v-glaza-kassandre-i-ne-poteryat-pri-etom-dannye-stabilnost-i-veru-v-nosql\/"},"modified":"2019-10-31T22:18:27","modified_gmt":"2019-10-31T19:18:27","slug":"kak-zaglyanut-v-glaza-kassandre-i-ne-poteryat-pri-etom-dannye-stabilnost-i-veru-v-nosql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/kak-zaglyanut-v-glaza-kassandre-i-ne-poteryat-pri-etom-dannye-stabilnost-i-veru-v-nosql","title":{"rendered":"Cum s\u0103 prive\u0219ti \u00een ochii Cassandrei f\u0103r\u0103 a pierde date, stabilitate \u0219i credin\u021b\u0103 \u00een NoSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Cum
\n<\/p>\n

Se spune c\u0103 \u00een via\u021b\u0103 trebuie s\u0103 \u00eencerci totul m\u0103car o dat\u0103. \u0218i dac\u0103 e\u0219ti obi\u0219nuit s\u0103 lucrezi cu SGBD-uri rela\u021bionale, merit\u0103 s\u0103 te familiarizezi practic cu NoSQL, m\u0103car pentru dezvoltarea general\u0103. Acum, datorit\u0103 evolu\u021biei rapide a acestei tehnologii, exist\u0103 multe opinii contradictorii \u0219i dispute aprinse pe aceast\u0103 tem\u0103, ceea ce st\u00e2rne\u0219te \u0219i mai mult interesul.
\nDac\u0103 te aprofundezi \u00een esen\u021ba tuturor acestor dispute, po\u021bi observa c\u0103 ele apar din cauza unei abord\u0103ri gre\u0219ite. Cei care folosesc baze de date NoSQL acolo unde sunt necesare sunt mul\u021bumi\u021bi \u0219i ob\u021bin toate avantajele acestei solu\u021bii. Iar experimentatorii, care se bazeaz\u0103 pe aceast\u0103 tehnologie ca pe o panacee acolo unde nu este aplicabil\u0103 deloc, sufer\u0103 dezam\u0103giri, pierz\u00e2nd punctele forte ale bazelor de date rela\u021bionale f\u0103r\u0103 a c\u00e2\u0219tiga beneficii semnificative.<\/p>\n

<\/p>\n

Voi povesti despre experien\u021ba noastr\u0103 de implementare a unei solu\u021bii bazate pe SGBD Cassandra: cu ce am fost nevoi\u021bi s\u0103 ne confrunt\u0103m, cum am reu\u0219it s\u0103 dep\u0103\u0219im situa\u021bii dificile, dac\u0103 am reu\u0219it s\u0103 ob\u021binem un avantaj din utilizarea NoSQL \u0219i unde a fost nevoie s\u0103 investim eforturi\/surse suplimentare.
\nSarcina ini\u021bial\u0103 a fost construirea unui sistem care \u00eenregistreaz\u0103 apelurile \u00eentr-un anumit depozit.<\/p>\n

<\/p>\n

Principiul de func\u021bionare al sistemului este urm\u0103torul. La intrare, vin fi\u0219iere cu o structur\u0103 specific\u0103, care descrie structura apelului. Apoi, aplica\u021bia asigur\u0103 salvarea acestei structuri \u00een coloanele corespunz\u0103toare. Ulterior, apelurile salvate sunt utilizate pentru a afi\u0219a informa\u021bii despre consumul de trafic pentru abona\u021bi (factur\u0103ri, apeluri, istoricul soldului).<\/p>\n

\n\"Cum<\/p>\n

De ce am ales Cassandra este destul de clar \u2014 scrie ca un mitralier\u0103, este u\u0219or scalabil\u0103, rezistent\u0103 la erori.<\/p>\n

\n<\/a><\/noindex><\/p>\n

Deci, iat\u0103 ce ne-a adus experien\u021ba<\/h2>\n

<\/p>\n

Da, o nod\u0103 c\u0103zut\u0103 nu este o tragedie. Asta este esen\u021ba rezisten\u021bei Cassandra. Dar o nod\u0103 poate fi activ\u0103 \u0219i totu\u0219i s\u0103 \u00eenceap\u0103 s\u0103 coboare \u00een performan\u021b\u0103<\/b>. A\u0219a cum s-a dovedit, asta se reflect\u0103 imediat asupra performan\u021bei \u00eentregului cluster.<\/p>\n

<\/p>\n

Cassandra nu va proteja acolo unde Oracle a salvat cu constr\u00e2ngerile sale<\/b>. \u0218i dac\u0103 autorul aplica\u021biei nu a \u00een\u021beles acest lucru din timp, atunci o dublur\u0103 ajuns\u0103 \u00een Cassandra nu este cu nimic mai prejos dec\u00e2t originalul. Daca a venit, atunci s\u0103 o inser\u0103m.<\/p>\n

<\/p>\n

Cassandra gratuit\u0103 \u201edin cutie\u201d nu a pl\u0103cut deloc securit\u0103\u021bii informa\u021biei: nu exist\u0103 logare a ac\u021biunilor utilizatorilor, nici o delimitare a drepturilor<\/b>. Informa\u021biile despre apeluri se refer\u0103 la date personale, ceea ce \u00eenseamn\u0103 c\u0103 toate \u00eencerc\u0103rile de a le solicita\/schimba \u00een orice mod trebuie s\u0103 fie jurnalizate cu posibilitatea de audit ulterior. De asemenea, trebuie s\u0103 con\u0219tientiz\u0103m necesitatea de a separa drepturile pe diferite niveluri pentru diferi\u021bi utilizatori. Un inginer de operare obi\u0219nuit \u0219i un super-admin care poate \u0219terge liber \u00eentregul keyspace sunt roluri diferite, cu responsabilit\u0103\u021bi \u0219i competen\u021be diferite. F\u0103r\u0103 o astfel de delimitare a drepturilor de acces, valoarea \u0219i integritatea datelor vor fi imediat puse sub semnul \u00eentreb\u0103rii mai repede dec\u00e2t la un nivel de consisten\u021b\u0103 ANY. <\/p>\n

<\/p>\n

Nu am luat \u00een considerare c\u0103 pentru apeluri este nevoie at\u00e2t de analize serioase, c\u00e2t \u0219i de extrageri periodice \u00een func\u021bie de cele mai variate condi\u021bii. Deoarece \u00eenregistr\u0103rile selectate urmeaz\u0103 s\u0103 fie \u0219terse \u0219i rescrise (\u00een cadrul sarcinii trebuie s\u0103 men\u021binem procesul de actualizare a datelor \u00een cazul \u00een care datele ini\u021bial primite \u00eencontur sunt eronate), Cassandra nu ne este de ajutor aici. Cassandra, ca o pu\u0219culi\u021b\u0103 \u2013 este convenabil s\u0103 pui \u00een ea, dar nu po\u021bi s\u0103 faci calcule.<\/b><\/p>\n

<\/p>\n

Ne-am confruntat cu problema transferului de date \u00een zonele de testare<\/b> (5 noduri \u00een test fa\u021b\u0103 de 20 \u00een produc\u021bie). \u00cen acest caz, nu se poate folosi un dump.<\/p>\n

<\/p>\n

Problema actualiz\u0103rilor schemei de date pentru aplica\u021bia care scrie \u00een Cassandra. Rollback-ul va genera o mare cantitate de tombstones, ceea ce poate afecta \u00een mod imprevizibil performan\u021ba<\/b>. Cassandra este optimizat\u0103 pentru scriere \u0219i, \u00eenainte de a scrie, nu se g\u00e2nde\u0219te mult. Orice opera\u021bie cu date existente \u00een ea este, de asemenea, o scriere. Adic\u0103, \u0219terg\u00e2nd datele inutile, vom crea doar mai multe \u00eenregistr\u0103ri, iar doar o parte dintre acestea vor fi marcate ca tombstones.<\/p>\n

<\/p>\n

Timeout-uri la inserare. Cassandra este excelent\u0103 la scriere, dar uneori fluxul de intrare o poate deruta considerabil<\/b>. Acest lucru se \u00eent\u00e2mpl\u0103 atunci c\u00e2nd aplica\u021bia \u00eencepe s\u0103 roteasc\u0103 mai multe \u00eenregistr\u0103ri care nu pot fi inserate dintr-un anumit motiv. \u0218i vom avea nevoie de un DBA adev\u0103rat, care s\u0103 monitorizeze gc.log, logurile system \u0219i debug pentru interog\u0103ri lente, \u0219i metricele pentru compaction pending.\n<\/p>\n

<\/p>\n

Mai multe centre de date \u00een cluster. De unde s\u0103 citim \u0219i unde s\u0103 scriem?<\/b>
\nEste posibil s\u0103 \u00eemp\u0103r\u021bim \u00eentre citire \u0219i scriere? \u0218i dac\u0103 da, ar trebui s\u0103 fie un D.C. pentru scriere sau pentru citire, mai aproape de aplica\u021bie? Nu ne-ar provoca oare o adev\u0103rat\u0103 divizare a creierului dac\u0103 alegem gre\u0219it nivelul de coeren\u021b\u0103? Avem foarte multe \u00eentreb\u0103ri, multe set\u0103ri neexplorate, oportunit\u0103\u021bi pe care ne-ar pl\u0103cea s\u0103 le ajust\u0103m.\n<\/p>\n

<\/p>\n

Cum am rezolvat problemele<\/h2>\n

<\/p>\n

Pentru a evita c\u0103derea nodului, am dezactivat SWAP.<\/b>. \u0218i acum, \u00een caz de memorie insuficient\u0103, nodul ar trebui s\u0103 se opreasc\u0103, nu s\u0103 creeze pauze lungi de gc.<\/p>\n

<\/p>\n

A\u0219adar, nu mai avem \u00eencredere \u00een logica din baza de date. Dezvoltatorii aplica\u021biei se reeduc\u0103 \u0219i \u00eencepe s\u0103 implementeze m\u0103suri de precau\u021bie activ \u00een codul lor.<\/b> O separare clar\u0103 \u0219i perfect\u0103 \u00eentre stocarea \u0219i procesarea datelor.<\/p>\n

<\/p>\n

Am achizi\u021bionat suport de la DataStax.<\/b> Cassandra \u00een versiune cutie a fost deja oprit\u0103 din dezvoltare (ultimul commit a fost \u00een februarie 2018). \u00centre timp, DataStax ofer\u0103 un serviciu excelent \u0219i o mul\u021bime de solu\u021bii adaptate \u0219i \u00eembun\u0103t\u0103\u021bite pentru sistemele existente.<\/p>\n

<\/p>\n

De asemenea, a\u0219 dori s\u0103 subliniez c\u0103 Cassandra nu este foarte convenabil\u0103 pentru interog\u0103rile de selec\u021bie. Desigur, CQL reprezint\u0103 un mare progres pentru utilizatori (\u00een compara\u021bie cu Thrift). Dar dac\u0103 ave\u021bi \u00eentregi departamente obi\u0219nuite cu astfel de join-uri convenabile, filtrarea liber\u0103 dup\u0103 orice c\u00e2mp \u0219i capacit\u0103\u021bile de optimizare a interog\u0103rilor, iar aceste departamente lucreaz\u0103 pentru a rezolva revendic\u0103rile \u0219i incidentele, atunci o solu\u021bie bazat\u0103 pe Cassandra li se pare o alegere neprietenos \u0219i stupid\u0103. \u0218i am \u00eenceput s\u0103 c\u0103ut\u0103m modalit\u0103\u021bi prin care colegii no\u0219tri s\u0103 fac\u0103 selec\u021bii. <\/p>\n

<\/p>\n

Am examinat dou\u0103 op\u021biuni. \u00cen prima op\u021biune, scriem apelurile nu doar \u00een C*, ci \u0219i \u00een baza de date arhiv\u0103 Oracle. Spre deosebire de C*, \u00een aceast\u0103 baz\u0103 de date sunt stocate apelurile doar pentru luna curent\u0103 (ad\u00e2ncimea de stocare a apelurilor este suficient\u0103 pentru cazurile de re\u021barifizare). Aici se contura imediat urm\u0103toarea problem\u0103: dac\u0103 scriem sincron, pierdem toate avantajele C*, legate de inserarea rapid\u0103; dac\u0103 scriem asincron \u2013 nu exist\u0103 nicio garan\u021bie c\u0103 toate apelurile necesare ajung \u00een Oracle. Un avantaj, dar mare: pentru exploatare, avem la dispozi\u021bie acela\u0219i familiar PL\/SQL Developer, adic\u0103 practic implement\u0103m modelul \u201eFasada\u201d. Op\u021biunea alternativ\u0103. Implement\u0103m un mecanism care extrage apelurile din C*, trage unele date pentru \u00eembog\u0103\u021bire din tabelele corespunz\u0103toare din Oracle, face joiun\u021bi ale selec\u021biilor ob\u021binute \u0219i ne ofer\u0103 rezultatul ob\u021binut, pe care ulterior \u00eel folosim cumva (\u00eel anular\u0103m, \u00eel repet\u0103m, \u00eel analiz\u0103m, ne bucur\u0103m de el). Dezavantaje: procesul devine destul de complex, \u0219i \u00een plus, lipse\u0219te o interfa\u021b\u0103 pentru angaja\u021bii de exploatare.<\/p>\n

<\/p>\n

\u00cen cele din urm\u0103, ne-am oprit totu\u0219i asupra celei de-a doua op\u021biuni. Pentru selec\u021bii din diferite baze de date, am folosit Apache Spark.<\/b> Esenta mecanismului a fost reducerea la un cod Java care, pe baza cheilor specificate (abonat, timp de apel \u2013 cheile sec\u021biunii), extrage date din C*, precum \u0219i datele necesare pentru \u00eembog\u0103\u021bire din orice alt\u0103 baz\u0103 de date. Apoi, le combin\u0103 \u00een memorie \u0219i afi\u0219eaz\u0103 rezultatul \u00een tabela de rezultate. Peste Spark, am desenat o interfa\u021b\u0103 web \u0219i a ie\u0219it destul de adecvat pentru exploatare.<\/p>\n

\n\"Cum<\/p>\n

\u00cen abordarea problemei actualiz\u0103rii datelor, echipa de testare a analizat din nou mai multe metode de solu\u021bionare. At\u00e2t transferul prin Sstloader, c\u00e2t \u0219i op\u021biunea de a \u00eemp\u0103r\u021bi clusterul \u00een zona de testare \u00een dou\u0103 p\u0103r\u021bi, fiecare dintre care intra alternativ \u00eentr-un cluster cu cel de produc\u021bie, aliment\u00e2ndu-se astfel de la acesta. La actualizarea testului, se pl\u0103nuia schimbarea loca\u021biilor: partea care func\u021biona \u00een test era cur\u0103\u021bat\u0103 \u0219i introdus\u0103 \u00een produc\u021bie, iar cealalt\u0103 \u00eencepea s\u0103 lucreze cu datele separat. Totu\u0219i, dup\u0103 o reanaliz\u0103, am evaluat mai ra\u021bional datele care merit\u0103 transferate \u0219i am realizat c\u0103 apelurile \u00een sine sunt o entitate inconsistent\u0103 pentru teste, generat\u0103 rapid \u00een caz de nevoie, iar setul de date de produc\u021bie nu are valoare pentru a fi transferat \u00een test. Sunt c\u00e2teva obiecte de stocare care merit\u0103 transferate, dar sunt literalmente doar c\u00e2teva tabele, \u0219i nu foarte grele. A\u0219adar, noi am apelat din nou la Spark ca solu\u021bie, cu ajutorul c\u0103ruia am scris \u0219i am \u00eenceput s\u0103 utiliz\u0103m activ un script pentru transferul datelor \u00eentre tabelele de produc\u021bie \u0219i test.<\/b><\/p>\n

<\/p>\n

Politica noastr\u0103 actual\u0103 de desf\u0103\u0219urare ne permite s\u0103 lucr\u0103m f\u0103r\u0103 rollback-uri.<\/b> \u00cenainte de produc\u021bie, este obligatoriu s\u0103 se efectueze un test, unde erorile nu cost\u0103 at\u00e2t de mult. \u00cen cazul unui e\u0219ec, este \u00eentotdeauna posibil s\u0103 \u0219tergem case-ul \u0219i s\u0103 reinstal\u0103m schema de la \u00eenceput.<\/p>\n

<\/p>\n

Pentru a asigura disponibilitatea continu\u0103 a Cassandra, este nevoie de un DBA \u0219i nu doar de el. To\u021bi cei care lucreaz\u0103 cu aplica\u021bia trebuie s\u0103 \u00een\u021beleag\u0103 unde \u0219i cum s\u0103 verifice situa\u021bia actual\u0103 \u0219i cum s\u0103 diagnosticheze problemele la timp.<\/b> Pentru aceasta, folosim activ DataStax OpsCenter (Administrare \u0219i monitorizare a sarcinilor de lucru), metricele sistemului Cassandra Driver (num\u0103rul de time-out-uri la scriere \u00een C*, num\u0103rul de time-out-uri la citire din C*, laten\u021ba maxim\u0103 etc.), monitoriz\u0103m func\u021bionarea aplica\u021biei \u00een sine care lucreaz\u0103 cu Cassandra.\n<\/p>\n

<\/p>\n

C\u00e2nd am reflectat asupra \u00eentreb\u0103rii anterioare, ne-am dat seama unde ar putea fi principala noastr\u0103 riscuri. Acestea sunt formele de prezentare a datelor care extrag informa\u021bii din mai multe cereri independente c\u0103tre depozit. Astfel, putem ob\u021bine o informa\u021bie destul de incoerent\u0103. Dar aceast\u0103 problem\u0103 ar fi relevant\u0103 \u0219i dac\u0103 am lucra doar cu un singur data center. A\u0219adar, cea mai logic\u0103 solu\u021bie ar fi, desigur, s\u0103 implement\u0103m o func\u021bie de citire a datelor \u00eentr-o aplica\u021bie extern\u0103, care s\u0103 asigure ob\u021binerea datelor \u00eentr-o perioad\u0103 unic\u0103 de timp. \u00cen ceea ce prive\u0219te separarea citirii \u0219i scrierii din perspectiva performan\u021bei, aici ne-a oprit riscul c\u0103, \u00een cazul unei pierderi temporare de conectivitate \u00eentre DC-uri, am putea ob\u021bine dou\u0103 clustere complet incoerente.<\/p>\n

<\/p>\n

Astfel, \u00een prezent ne-am oprit la nivelul de coeren\u021b\u0103 pentru scriere EACH_QUORUM, iar pentru citire \u2013 LOCAL_QUORUM<\/b><\/p>\n

<\/p>\n

Impresii \u0219i concluzii scurte<\/h2>\n

<\/p>\n

Pentru a evalua solu\u021bia ob\u021binut\u0103 din perspectiva suportului opera\u021bional \u0219i a posibilit\u0103\u021bilor de dezvoltare ulterioar\u0103, am decis s\u0103 ne g\u00e2ndim unde am putea aplica o astfel de dezvoltare.<\/p>\n

<\/p>\n

Dac\u0103 ne g\u00e2ndim rapid, scorarea datelor pentru programe precum \u201ePl\u0103te\u0219te c\u00e2nd \u00ee\u021bi convine\u201d (\u00eenc\u0103rc\u0103m informa\u021bii \u00een S*, calcul pe scripturi Spark), gestionarea pl\u00e2ngerilor cu agregare pe direc\u021bii, p\u0103strarea rolurilor \u0219i calcularea pe matricea de roluri a drepturilor de acces ale utilizatorilor. <\/p>\n

<\/p>\n

Dup\u0103 cum vedem, repertoriul este larg \u0219i divers. \u0218i dac\u0103 ar fi s\u0103 alegem tab\u0103ra sus\u021bin\u0103torilor\/propagandi\u0219tilor NoSQL, am adera la sus\u021bin\u0103tori, deoarece am ob\u021binut avantajele dorite, exact acolo unde ne a\u0219teptam.<\/p>\n

<\/p>\n

Chiar \u0219i varianta Cassandra din cutie permite scalarea orizontal\u0103 \u00een timp real, rezolv\u00e2nd absolut f\u0103r\u0103 durere problema cre\u0219terii datelor \u00een sistem. Am reu\u0219it s\u0103 externaliz\u0103m un mecanism cu o foarte mare \u00eenc\u0103rcare pentru calculul agregatelor pe apeluri \u0219i, \u00een plus, s\u0103 separ\u0103m schema \u0219i logica aplica\u021biei, sc\u0103p\u00e2nd de practica nociv\u0103 a scrierii joburilor personalizate \u0219i obiectelor \u00een baza de date \u00een sine. Am ob\u021binut posibilitatea de a alege \u0219i a configura, pentru accelerare, pe care DC-uri vom efectua calculul \u0219i pe care le vom utiliza pentru scrierea datelor, asigur\u00e2ndu-ne \u00eempotriva pr\u0103bu\u0219irii at\u00e2t a nodurilor individuale, c\u00e2t \u0219i a \u00eentregului DC.<\/p>\n

<\/p>\n

Aplic\u00e2nd arhitectura noastr\u0103 la noi proiecte, \u0219i av\u00e2nd deja o anumit\u0103 experien\u021b\u0103, ne-am dori s\u0103 lu\u0103m imediat \u00een considerare nuan\u021bele men\u021bionate mai sus \u0219i s\u0103 evit\u0103m anumite erori, s\u0103 estomp\u0103m col\u021burile ascu\u021bite, care nu au putut fi evitate ini\u021bial.<\/p>\n

<\/p>\n

De exemplu, s\u0103 urm\u0103rim \u00een timp util actualiz\u0103rile versiunii Cassandra<\/b>, deoarece multe dintre problemele pe care le-am avut erau deja cunoscute \u0219i au fost remediate.<\/p>\n

<\/p>\n

S\u0103 nu instal\u0103m at\u00e2t baza de date, c\u00e2t \u0219i Spark pe acelea\u0219i noduri<\/b> (sau s\u0103 le separ\u0103m strict \u00een func\u021bie de cantitatea de resurse utilizabile), deoarece Spark poate consuma mai mult RAM dec\u00e2t ar trebui, iar noi vom avea rapid problema num\u0103rul 1 din lista noastr\u0103.<\/p>\n

<\/p>\n

S\u0103 \u00eembun\u0103t\u0103\u021bim monitorizarea \u0219i competen\u021bele de operare \u00eenc\u0103 din etapa de testare a proiectului. <\/b>Ini\u021bial, s\u0103 lu\u0103m \u00een considerare to\u021bi consumatorii poten\u021biali ai solu\u021biei noastre<\/b>, deoarece tocmai de acest lucru va depinde, \u00een cele din urm\u0103, structura bazei de date.<\/p>\n

<\/p>\n

S\u0103 examin\u0103m schema ob\u021binut\u0103 de c\u00e2teva ori pentru a c\u0103uta eventuale optimiz\u0103ri. S\u0103 identific\u0103m ce c\u00e2mpuri pot fi serializate. S\u0103 \u00een\u021belegem ce tabele suplimentare trebuie s\u0103 facem pentru a lua \u00een considerare, \u00een mod c\u00e2t mai corect \u0219i optim, \u0219i ulterioar\u0103 livrare a informa\u021biilor solicitate (de exemplu, av\u00e2nd \u00een vedere c\u0103 acelea\u0219i date pot fi stocate \u00een tabele diferite, conform diferitelor criterii de fragmentare, putem economisi semnificativ timpul de procesor \u00een timpul cererilor de citire).<\/p>\n

<\/p>\n

Este bine s\u0103 prevedem imediat ata\u0219area TTL \u0219i cur\u0103\u021barea datelor dep\u0103\u0219ite.<\/b><\/p>\n

<\/p>\n

La exportul de date din Cassandra logica aplica\u021biei ar trebui s\u0103 func\u021bioneze pe principiul FETCH, astfel \u00eenc\u00e2t nu toate r\u00e2ndurile s\u0103 fie \u00eenc\u0103rcate \u00een memorie deodat\u0103, ci s\u0103 fie selectate pe grupe.<\/b><\/p>\n

<\/p>\n

Este recomandat s\u0103 verific\u0103m rezilien\u021ba sistemului \u00eenainte de a muta proiectul pe solu\u021bia descris\u0103, realiz\u00e2nd o serie de teste de stres<\/b>, cum ar fi pierderea datelor \u00eentr-un centru de date, recuperarea datelor deteriorate pe o anumit\u0103 perioad\u0103, sc\u0103derea re\u021belei \u00eentre centrele de date. Aceste teste nu doar vor permite evaluarea avantajelor \u0219i dezavantajelor arhitecturii propuse, ci vor oferi \u0219i o bun\u0103 practic\u0103 pentru inginerii care le efectueaz\u0103, iar abilit\u0103\u021bile ob\u021binute nu vor fi \u00een zadar, mai ales dac\u0103 defec\u021biunile sistemului se vor repeta \u00een produc\u021bie.<\/p>\n

<\/p>\n

Dac\u0103 lucr\u0103m cu informa\u021bii critice (cum ar fi datele pentru facturare, calcularea datoriilor abonatului), atunci ar trebui s\u0103 acord\u0103m aten\u021bie instrumentelor care permit reducerea riscurilor, care apar din cauza specificului SGBD-ului. De exemplu, folosirea utilitarului nodesync (Datastax), elabor\u00e2nd o strategie optim\u0103 pentru utilizarea acestuia, pentru a nu forma o \u00eenc\u0103rc\u0103tur\u0103 excesiv\u0103 asupra Cassandra,<\/b> \u0219i a-l utiliza doar pentru anumite tabele \u00eentr-o anumit\u0103 perioad\u0103.<\/p>\n

<\/p>\n

Deci, dup\u0103 \u0219ase luni de utilizare a Cassandra? \u00cen general, nu exist\u0103 probleme nerezolvate. Nu am avut accidente serioase \u0219i pierderi de date. Da, a fost necesar s\u0103 ne g\u00e2ndim la compensa\u021bia unor probleme care nu au mai ap\u0103rut anterior, dar \u00een final acest lucru nu a umbrit prea mult solu\u021bia noastr\u0103 arhitectural\u0103. Dac\u0103 dori\u021bi \u0219i nu v\u0103 temea\u021bi s\u0103 \u00eencerca\u021bi ceva nou, \u0219i \u00een acela\u0219i timp nu dori\u021bi s\u0103 fi\u021bi foarte dezam\u0103gi\u021bi, preg\u0103ti\u021bi-v\u0103 pentru faptul c\u0103 nimic nu este gratuit. Va trebui s\u0103 \u00eenv\u0103\u021ba\u021bi, s\u0103 studia\u021bi documenta\u021bia \u0219i s\u0103 v\u0103 str\u00e2nge\u021bi propriile capcane mai mult dec\u00e2t \u00een solu\u021bia veche legacy, iar nicio teorie nu v\u0103 va spune din timp ce capcane v\u0103 a\u0219teapt\u0103 exact pe dumneavoastr\u0103.<\/p>\n

Sursa: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0413\u043e\u0432\u043e\u0440\u044f\u0442, \u0432 \u0436\u0438\u0437\u043d\u0438 \u0432\u0441\u0435 \u0441\u0442\u043e\u0438\u0442 \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c \u0445\u043e\u0442\u044f \u0431\u044b \u0440\u0430\u0437. \u0418 \u0435\u0441\u043b\u0438 \u0432\u044b \u043f\u0440\u0438\u0432\u044b\u043a\u043b\u0438 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0441 \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u044b\u043c\u0438 \u0421\u0423\u0411\u0414, \u0442\u043e \u043f\u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u043d\u0430 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0435 \u0441 NoSQL \u0441\u0442\u043e\u0438\u0442 \u0432 \u043f\u0435\u0440\u0432\u0443\u044e \u043e\u0447\u0435\u0440\u0435\u0434\u044c \u0445\u043e\u0442\u044f \u0431\u044b \u0434\u043b\u044f \u043e\u0431\u0449\u0435\u0433\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f. \u0421\u0435\u0439\u0447\u0430\u0441 \u0432 \u0441\u0438\u043b\u0443 \u0431\u0443\u0440\u043d\u043e\u0433\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f \u044d\u0442\u043e\u0439 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438 \u043e\u0447\u0435\u043d\u044c \u043c\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0442\u0438\u0432\u043e\u0440\u0435\u0447\u0438\u0432\u044b\u0445 \u043c\u043d\u0435\u043d\u0438\u0439 \u0438 \u0433\u043e\u0440\u044f\u0447\u0438\u0445 \u0441\u043f\u043e\u0440\u043e\u0432 \u043d\u0430 \u044d\u0442\u0443 \u0442\u0435\u043c\u0443, \u0447\u0442\u043e \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u043f\u043e\u0434\u043e\u0433\u0440\u0435\u0432\u0430\u0435\u0442 \u0438\u043d\u0442\u0435\u0440\u0435\u0441. \u0415\u0441\u043b\u0438 \u0432\u043d\u0438\u043a\u043d\u0443\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28210,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37585","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Cum s\u0103 prive\u0219ti \u00een ochii Cassandra \u0219i s\u0103 nu pierzi datele, stabilitatea \u0219i \u00eencrederea \u00een NoSQL | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/kak-zaglyanut-v-glaza-kassandre-i-ne-poteryat-pri-etom-dannye-stabilnost-i-veru-v-nosql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u0437\u0430\u0433\u043b\u044f\u043d\u0443\u0442\u044c \u0432 \u0433\u043b\u0430\u0437\u0430 \u041a\u0430\u0441\u0441\u0430\u043d\u0434\u0440\u0435 \u0438 \u043d\u0435 \u043f\u043e\u0442\u0435\u0440\u044f\u0442\u044c \u043f\u0440\u0438 \u044d\u0442\u043e\u043c \u0434\u0430\u043d\u043d\u044b\u0435, \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u0432\u0435\u0440\u0443 \u0432 NoSQL | ProHoster","og:description":".","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/kak-zaglyanut-v-glaza-kassandre-i-ne-poteryat-pri-etom-dannye-stabilnost-i-veru-v-nosql","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:18:27+00:00","article:modified_time":"2019-10-31T19:18:27+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37585","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 18:29:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:06:01","updated":"2026-01-23 18:29:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/37585","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=37585"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/37585\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/28210"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=37585"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=37585"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=37585"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}