Dicenu chì tuttu in a vita vale a pena pruvà almenu una volta. E s'è vo site abituatu à travaglià cù DBMSs relazionale, allora vale a pena cunnosce NoSQL in pratica, prima di tuttu, almenu per u sviluppu generale. Avà, per via di u rapidu sviluppu di sta tecnulugia, ci sò assai opinioni cunflitti è dibattiti caldi nantu à questu tema, chì in particulare alimenta l'interessu.
S'è vo sfondate in l'essenza di tutti sti disputi, pudete vede chì si sviluppanu per via di l'approcciu sbagliatu. Quelli chì utilizanu basa di dati NoSQL esattamente induve sò necessarii sò soddisfatti è ricevenu tutti i vantaghji da sta suluzione. E sperimentatori chì si basanu nantu à sta tecnulugia cum'è una panacea induve ùn hè micca applicabile à tutti sò disappruvati, avè persu i punti di forza di e basa di dati relazionale senza ottene benefici significativi.
Vi cuntaraghju di a nostra sperienza in l'implementazione di una soluzione basata nantu à u DBMS Cassandra: ciò chì avemu avutu à affruntà, cumu avemu surtitu da situazioni difficili, s'ellu pudemu prufittà di l'usu di NoSQL è induve duvemu investisce sforzi / fondi supplementari. .
U compitu iniziale hè di custruisce un sistema chì registra e chjama in qualchì tipu di almacenamiento.
U principiu di u funziunamentu di u sistema hè a siguenti. L'input include schedarii cù una struttura specifica chì descrive a struttura di a chjama. L'applicazione poi assicura chì sta struttura hè guardata in e culonne apprupriate. In u futuru, i chjamati salvati sò usati per vede infurmazioni nantu à u cunsumu di trafficu per l'abbonati (carichi, chjamati, storia di equilibriu).
Hè abbastanza chjaru perchè anu sceltu Cassandra - scrive cum'è una mitragliatrice, hè facilmente scalabile è tolerante à i difetti.
Dunque, questu hè ciò chì l'esperienza ci hà datu
Iè, un node fallutu ùn hè micca una tragedia. Questa hè l'essenza di a tolleranza di a colpa di Cassandra. Ma un node pò esse vivu è à u stessu tempu cumincià à soffre in u performance. Cum'è hè risultatu, questu affetta immediatamente u rendiment di u cluster sanu.
Cassandra ùn vi prutege micca induve Oracle vi hà salvatu cù e so limitazioni. È se l'autore di l'applicazione ùn hà micca capitu questu in anticipu, allora u doppiu chì hè ghjuntu per Cassandra ùn hè micca peghju di l'uriginale. Una volta hè ghjuntu, l'avemu messu.
IB hà assai disgustatu a Cassandra libera fora di a scatula: Ùn ci hè micca logu di l'azzioni di l'utilizatori, nè differenziazione di diritti. L'infurmazioni nantu à e chjamate sò cunsiderate dati persunali, chì significa chì tutti i tentativi di dumandà / cambià in ogni modu deve esse registratu cù a pussibilità di auditing sussegwenti. Inoltre, avete bisognu à esse cuscenti di a necessità di separà i diritti à diversi livelli per diversi utilizatori. Un ingegnere di operazione simplice è un super amministratore chì pò sguassà liberamente tuttu u spaziu chjave sò diversi roli, diverse responsabilità è cumpetenze. Senza una tale differenziazione di diritti d'accessu, u valore è l'integrità di e dati seranu subitu in quistione più veloce chì cù u livellu di cunsistenza ANY.
Ùn avemu micca cunsideratu chì e chjama necessitanu sia analitiche serii sia campioni periodichi per una varietà di cundizioni. Siccomu i registri selezziunati sò allora supponi esse sguassati è riscritti (cum'è parte di u compitu, duvemu sustene u prucessu di aghjurnà e dati quandu i dati inizialmente entravanu in u nostru ciclu incorrectamente), Cassandra ùn hè micca u nostru amicu quì. Cassandra hè cum'è un piggy bank - hè cunvenutu per mette e cose, ma ùn pudete micca cuntà in questu.
Avemu scontru un prublema di trasferimentu di dati à e zone di teste (5 nodi in a prova versus 20 in u prom). In questu casu, u dump ùn pò micca esse usatu.
U prublema cù l'aghjurnamentu di u schema di dati di una applicazione chì scrive à Cassandra. Un rollback genererà una grande quantità di lapidi, chì ponu purtà à perdite di produtividade in modu imprevisible.. Cassandra hè ottimizatu per a registrazione, è ùn pensa micca assai prima di scrive. Qualchese operazione cù dati esistenti in questu hè ancu una registrazione. Vale à dì, sguassendu l'innecessariu, simpricimenti pruduceremu ancu più dischi, è solu alcuni di elli seranu marcati cù lapidi.
Timeouts quandu si inserisce. Cassandra hè bella in a registrazione, ma qualchì volta u flussu entrante pò significativamente perplessa. Stu succèri quandu l 'applicazzioni principia à ciclu intornu à parechji dischi chì ùn pò esse inseritu per qualchi mutivu. È avemu bisognu di un veru DBA chì monitorerà gc.log, logs di sistema è di debug per e dumande lente, metriche nantu à a compactazione pendente.
Diversi centri di dati in un cluster. Da induve leghje è induve scrive ?
Forse divisu in lettura è scrittura? E s'ellu hè cusì, duverebbe esse un DC più vicinu à l'applicazione per scrive o leghje? È ùn avemu micca finitu cù un veru cervellu split s'ellu sceglie u livellu di cunsistenza sbagliata? Ci hè parechje dumande, assai paràmetri scunnisciuti, pussibulità chì vulete veramente chjappà.
Cumu avemu decisu
Per impediscenu u node di affundà, SWAP hè stata disattivata. È avà, s'ellu ci hè una mancanza di memoria, u node deve falà è micca creà grandi pause gc.
Dunque, ùn avemu più basa di a logica in a basa di dati. I sviluppatori di l'applicazioni si sò rifurmati è cumincianu à piglià precauzioni attivamente in u so propiu codice. Separazione chjara ideale di almacenamiento è trasfurmazioni di dati.
Avemu compru supportu da DataStax. U sviluppu di Cassandra boxed hà digià cessatu (l'ultimu impegnu era in February 2018). À u listessu tempu, Datastax offre un serviziu eccellente è un gran numaru di suluzioni mudificate è adattate per soluzioni IP esistenti.
Vogliu ancu nutà chì Cassandra ùn hè micca assai còmuda per e dumande di selezzione. Di sicuru, CQL hè un grande passu avanti per l'utilizatori (paragunatu à Trift). Ma s'è vo avete dipartimenti interi chì sò abituati à tali cunghjunghjini cunvene, filtru gratuitu da ogni campu è capacità di ottimisazione di quistione, è sti dipartimenti sò travagliendu per risolve lagnanza è accidenti, allora a suluzione nantu à Cassandra pare ostili è stupidu per elli. E avemu cuminciatu à decide cumu i nostri culleghi anu da fà campioni.
Avemu cunsideratu duie opzioni.In a prima opzione, scrivemu chjamate micca solu in C *, ma ancu in a basa di dati Oracle archiviata. Solu, à u cuntrariu di C *, sta basa di dati guarda e chjama solu per u mese currente (prufundità di almacenamentu di chjama sufficiente per i casi di ricarica). Quì avemu vistu subitu u prublema seguente: se scrivimu in modu sincronu, allora perdemu tutti i vantaghji di C * assuciati à l'inserzione rapida; se scrivimu in modu asincronu, ùn ci hè micca garanzia chì tutte e chjamate necessarie sò entrate in Oracle. Ci era un plus, ma un grande: per u funziunamentu, resta u stessu Sviluppatore PL / SQL famusu, vale à dì chì implementemu praticamenti u mudellu "Facade", una opzione alternativa. Implementemu un mecanismu chì scarica e chjama da C *, tira qualchi dati per l'arricchimentu da e tavule currispundenti in Oracle, unisce à i campioni resultanti è ci dà u risultatu, chì dopu avemu in qualchì modu usà (rottu, ripetite, analizà, ammirate). Cons: u prucessu hè abbastanza multi-passu, è in più, ùn ci hè micca una interfaccia per l'impiegati di u funziunamentu.
In fine, avemu stallatu nantu à a seconda opzione. Apache Spark hè stata utilizata per campionà da diverse vasi. L'essenza di u mecanismu hè stata ridutta à u codice Java, chì, utilizendu i chjavi specificati (abbonatu, tempu di chjama - chjavi di sezione), tira fora di dati da C *, è ancu i dati necessarii per l'arricchimentu da qualsiasi altra basa di dati. Dopu chì li unisce in a so memoria è mostra u risultatu in a tavola resultanti. Avemu tracciatu una faccia web nantu à a scintilla è hè diventata abbastanza utilizable.
Quandu risolve u prublema di l'aghjurnà di e dati di teste industriali, avemu ancu cunsideratu parechje suluzione. Tramindui u trasferimentu via Sstloader è l'opzione di sparte u cluster in a zona di prova in duie parti, ognuna appartene alternativamente à u stessu cluster cù u promozionale, cusì esse alimentatu da questu. Quandu l'aghjurnà a prova, era previstu di scambià: a parte chì hà travagliatu in a prova hè sguassata è intruta in a pruduzzione, è l'altru cumencia à travaglià cù e dati separatamente. In ogni casu, dopu à pensà à novu, avemu evaluatu più razionalmente i dati chì valeva a pena di trasfirià, è capitu chì i chjamati stessi sò una entità inconsistente per i testi, generati rapidamente se ne necessariu, è hè u settore di dati promozionale chì ùn hà micca valore per u trasferimentu à u prova. Ci sò parechji ogetti di almacenamento chì valenu a mossa, ma questi sò literalmente un paru di tavule, è micca assai pisanti. Dunque noi cum'è una suluzione, Spark torna torna à a salvezza, cù l'aiutu di quale avemu scrittu è cuminciaru à aduprà attivamente un script per trasfiriri dati trà tavule, prom-test.
A nostra pulitica di implementazione attuale ci permette di travaglià senza rollbacks. Prima di a prumuzione, ci hè una prova obligatoria, induve un sbagliu ùn hè micca cusì caru. In casu di fallimentu, pudete sempre abbandunà u casu è rollu tuttu u schema da u principiu.
Per assicurà a dispunibilità cuntinua di Cassandra, avete bisognu di un dba è micca solu ellu. Tutti quelli chì travaglianu cù l'applicazione anu da capisce induve è cumu guardà a situazione attuale è cumu diagnosticà i prublemi in una manera puntuale. Per fà questu, usemu attivamente DataStax OpsCenter (Amministrazione è monitoraghju di carichi di travagliu), metriche di sistema Cassandra Driver (numeru di timeouts per scrive à C *, numeru di timeouts per leghje da C *, latenza massima, etc.), monitorizà l'operazione. di l'applicazione stessa, travagliendu cù Cassandra.
Quandu avemu pensatu à a quistione precedente, avemu capitu induve puderia esse u nostru risicu principale. Quessi sò forme di visualizazione di dati chì mostranu dati da parechje dumande indipendenti à u almacenamiento. Questu modu pudemu avè infurmazioni abbastanza inconsistenti. Ma stu prublema seria cum'è pertinenti se avemu travagliatu cù un solu centru di dati. Allora u più ragiunate quì hè, sicuru, di creà una funzione batch per leghje dati nantu à una applicazione di terzu, chì assicurarà chì e dati sò ricevuti in un unicu periodu di tempu. In quantu à a divisione in a lettura è a scrittura in quantu à u rendiment, quì ci sò stati fermati da u risicu chì cù una certa perdita di cunnessione trà i DC, pudemu finisce cù dui clusters chì sò completamente inconsistenti l'una cù l'altru.
In u risultatu, per avà firmatu à u livellu di cunsistenza per scrive EACH_QUORUM, per leghje - LOCAL_QUORUM
Brevi impressioni è cunclusioni
Per valutà a suluzione risultante da u puntu di vista di u sustegnu operativu è e prospettive per u sviluppu ulteriore, avemu decisu di pensà à induve un tali sviluppu puderia esse applicatu.
Subbitu, dopu puntuazione di dati per prugrammi cum'è "Paga quandu hè cunvenutu" (carchemu l'infurmazioni in C *, calculu cù script Spark), cuntabili per e rivendicazioni cù aggregazione per zona, almacenà roli è calculà i diritti d'accessu di l'utilizatori basatu nantu à u rolu. matrice.
Comu pudete vede, u repertoriu hè largu è variatu. È s'ellu sceglie u campu di sustenidori / avversari di NoSQL, allora avemu da unisce à i sustenidori, postu chì avemu ricevutu i nostri vantaghji, è esattamente induve avemu aspittatu.
Ancu l'opzione Cassandra fora di a scatula permette a scala horizontale in tempu reale, risolve senza dolore u prublema di l'aumentu di dati in u sistema. Pudemu muvimenti un mecanismu di carica assai altu per u calculu di l'agregati di chjama in un circuitu separatu, è ancu separà u schema di l'applicazione è a logica, sguassate di a cattiva pratica di scrive impieghi persunalizati è oggetti in a basa di dati stessu. Avemu avutu l'uppurtunità di sceglie è cunfigurà, per accelerà, quali DC realiceremu calculi è quali registreremu dati, avemu assicuratu contra i crashes di i dui nodi individuali è di u DC in generale.
Applicà a nostra architettura à novi prughjetti, è avè digià una certa sperienza, mi piacerebbe piglià immediatamente in contu i sfumaturi descritti sopra, è impediscenu qualchì sbagliu, alliscià certi anguli sharp chì ùn pudianu esse evitati inizialmente.
Per esempiu, tene traccia di l'aghjurnamenti di Cassandra in una manera puntualeperchè un pocu di i prublemi chì avemu avutu era digià cunnisciutu è riparatu.
Ùn mette micca a basa di dati stessu è Spark nantu à i stessi nodi (o divisu strettamente da a quantità di usu di risorsa permessa), postu chì Spark pò manghjà più OP di l'aspittatu, è avemu da ottene rapidamente u prublema numeru 1 da a nostra lista.
Migliurà u monitoraghju è a cumpetenza operativa in a fase di prova di u prugettu. In principiu, piglià in contu quantu pussibule tutti i cunsumatori potenziali di a nostra suluzione, perchè questu hè ciò chì a struttura di basa di dati dependerà in ultimamente.
Rotate u circuitu resultanti parechje volte per ottimisazione pussibule. Selezziunà quali campi ponu esse serializatu. Capisce quali tavule supplementari duvemu fà per piglià in cunsiderà più currettamente è ottimali, è dopu furnisce l'infurmazioni necessarii nantu à a dumanda (per esempiu, assumendu chì pudemu almacenà i stessi dati in tabelle diverse, tenendu in contu e diverse scompartimenti secondu diversi criterii, pudemu risparmià significativamente u tempu di CPU per e richieste di lettura).
Micca malu Immediatamente furnisce l'attache TTL è a pulizia di dati obsoleti.
Quandu scaricate dati da Cassandra A logica di l'applicazione deve travaglià nantu à u principiu FETCH, perchè micca tutte e fila sò caricate in memoria in una volta, ma sò scelte in batch.
Hè cunsigliatu prima di trasfiriri u prugettu à a suluzione discrittu verificate a tolleranza à i difetti di u sistema cunducendu una seria di teste di crash, cum'è a perdita di dati in un centru di dati, risturazione di dati guastatu annantu à un certu periodu, abbandunamentu di a reta trà i centri di dati. Tali testi ùn permettenu micca solu di valutà i pro è i contra di l'architettura pruposta, ma ancu furnisce una bona pratica di riscaldamentu per l'ingegneri chì li conducenu, è a cumpetenza acquistata serà luntanu da superflua se i fallimenti di u sistema sò riprudutti in a produzzione.
Se avemu travagliatu cù l'infurmazioni critichi (cum'è dati per a fattura, u calculu di u debitu di l'abbonatu), allora vale a pena attente à e strumenti chì riduceranu i risichi per via di e caratteristiche di u DBMS. Per esempiu, utilizate l'utilità nodesync (Datastax), avè sviluppatu una strategia ottima per u so usu in ordine per a cunsistenza, ùn creanu micca una carica eccessiva nantu à Cassandra è aduprà solu per certi tavulini in un certu periodu.
Chì succede à Cassandra dopu à sei mesi di vita ? In generale, ùn ci sò micca prublemi senza risolve. Avemu dinù micca permessu ogni accidente seriu o perdita di dati. Iè, avemu avutu à pinsà à cumpensà qualchi prublemi chì ùn avianu micca accadutu prima, ma à a fine questu ùn hà micca annebbiatu assai a nostra suluzione architettonica. Se vulete è ùn avete micca paura di pruvà qualcosa di novu, è à u stessu tempu ùn vulete micca esse troppu disappuntu, allora preparate per u fattu chì nunda hè liberu. Avete da capisce, sfondate in a ducumentazione è assemblà u vostru propiu rake individuali più cà in l'antica suluzione legata, è nisuna teoria vi dicerà in anticipu quale rake vi aspetta.
Source: www.habr.com