<\/a><\/noindex><\/p>\nEcco cosa ci ha insegnato l'esperienza.<\/h2>\n <\/p>\n
S\u00ec, una node che va offline non \u00e8 una tragedia. \u00c8 questo il punto della resilienza di Cassandra. Ma una node pu\u00f2 essere attiva e allo stesso tempo iniziare a perdere prestazioni.<\/b>Come abbiamo scoperto, questo si riflette immediatamente sulle prestazioni dell'intero cluster.<\/p>\n
<\/p>\n
Cassandra non offre la stessa protezione che Oracle garantiva con i suoi vincoli.<\/b>E se lo sviluppatore dell'applicazione non lo ha capito in tempo, un duplicato in arrivo per Cassandra non \u00e8 affatto peggiore dell'originale. Se \u00e8 arrivato, lo inseriamo.<\/p>\n
<\/p>\n
La versione gratuita di Cassandra \"out of the box\" non \u00e8 piaciuta affatto agli esperti di sicurezza. non ci sono registri delle attivit\u00e0 degli utenti, n\u00e9 limitazioni sui diritti<\/b>. Le informazioni sulle chiamate riguardano dati personali, il che significa che tutte le tentativi di richiederli\/modificarli devono essere registrati con la possibilit\u00e0 di audit successivo. Inoltre, \u00e8 necessario essere consapevoli della necessit\u00e0 di separare i diritti a diversi livelli per diversi utenti. Un semplice ingegnere operativo e un superamministratore, che pu\u00f2 liberamente eliminare tutto il keyspace, hanno ruoli e responsabilit\u00e0 diverse. Senza una tale distinzione dei diritti di accesso, il valore e l'integrit\u00e0 dei dati saranno messi in discussione pi\u00f9 rapidamente rispetto a un livello di coerenza ANY. <\/p>\n
<\/p>\n
Non abbiamo considerato che per le chiamate sono necessarie sia analisi approfondite che campionamenti periodici in base a vari criteri. Poich\u00e9 le registrazioni scelte dovranno poi essere eliminate e riscritte (nell'ambito del compito dobbiamo supportare il processo di aggiornamento dei dati quando inizialmente abbiamo ricevuto dati errati), Cassandra qui non ci sar\u00e0 d'aiuto. Cassandra, come una cassaforte, \u00e8 comoda per accumulare dati, ma non \u00e8 adatta per i calcoli.<\/b><\/p>\n
<\/p>\n
Hai riscontrato un problema nel trasferimento dei dati nelle zone di test<\/b> (5 nodi in test contro 20 in produzione). In questo caso non sar\u00e0 possibile utilizzare un dump.<\/p>\n
<\/p>\n
Problema con gli aggiornamenti dello schema dei dati dell'applicazione che scrive su Cassandra. Un rollback generer\u00e0 un numero considerevole di tombstones, il che potrebbe influenzare in modo imprevedibile le nostre prestazioni.<\/b>. Cassandra \u00e8 ottimizzata per la scrittura e, prima di scrivere, non pensa molto. Qualsiasi operazione con i dati esistenti \u00e8 anch'essa una scrittura. Cio\u00e8, rimuovendo l'eccesso, generiamo semplicemente pi\u00f9 scritture, e solo una parte di esse sar\u00e0 contrassegnata come tombstones.<\/p>\n
<\/p>\n
Timeout durante l'inserimento. Cassandra \u00e8 eccellente nella scrittura, ma a volte il flusso in ingresso pu\u00f2 metterla seriamente in difficolt\u00e0.<\/b>. Questo accade quando l'applicazione inizia a girare in tondo su diverse scritture che non possono essere inserite per qualche motivo. E avremo bisogno di un vero DBA che monitori gc.log, i log di sistema e di debug in cerca di query lente, metriche su compaction pending.\n<\/p>\n
<\/p>\n
Diversi datacenter nel cluster. Da dove leggere e dove scrivere?<\/b>
<\/p>\n
Come abbiamo risolto<\/h2>\n <\/p>\n
Per evitare che il nodo crolli, abbiamo disattivato lo SWAP<\/b>. E ora, in caso di mancanza di memoria, il nodo deve andare gi\u00f9, invece di generare lunghe pause di gc.<\/p>\n
<\/p>\n
Quindi, non ci aspettiamo pi\u00f9 una logica nel DB. Gli sviluppatori dell'app stanno cambiando approccio e iniziano a coprirsi attivamente nel proprio codice.<\/b> Una separazione perfetta e chiara tra memorizzazione e elaborazione dei dati.<\/p>\n
<\/p>\n
Abbiamo acquistato supporto da DataStax.<\/b> Lo sviluppo della Cassandra box \u00e8 stato interrotto (l'ultimo commit \u00e8 stato effettuato a febbraio 2018). Nel frattempo, Datastax offre un ottimo servizio e molte soluzioni perfezionate e adattate ai sistemi esistenti.<\/p>\n
<\/p>\n
Vorrei anche notare che Cassandra non \u00e8 molto comoda per le query di estrazione. Certo, CQL rappresenta un grande passo avanti per gli utenti (rispetto a Trift). Ma se hai interi reparti abituati a join facili, a una filtrazione libera su qualsiasi campo e alle possibilit\u00e0 di ottimizzazione delle query, e questi reparti lavorano per risolvere reclami e guasti, allora la scelta di Cassandra sar\u00e0 vista da loro come ostile e sciocca. Abbiamo iniziato a risolvere come facilitare l'estrazione per i nostri colleghi. <\/p>\n
<\/p>\n
Abbiamo considerato due opzioni. Nella prima opzione registriamo le chiamate non solo in C*, ma anche nel database Oracle archiviato. A differenza di C*, in questo database vengono memorizzate solo le chiamate del mese corrente (un periodo di conservazione sufficiente per i casi di retroattivazione). Qui emergeva subito il seguente problema: se scriviamo in modo sincrono, perdiamo tutti i vantaggi di C* legati all'inserimento veloce; se in modo asincrono, non c'\u00e8 garanzia che tutte le chiamate necessarie siano arrivate effettivamente in Oracle. Tuttavia, c'era un grande vantaggio: per l'operativit\u00e0 rimane lo stesso familiare PL\/SQL Developer, cio\u00e8 praticamente possiamo implementare il pattern \"Facade\". L'alternativa: realizziamo un meccanismo che estrae le chiamate da C*, preleva alcuni dati per arricchire dalle tabelle corrispondenti in Oracle, unisce i risultati ottenuti e ci fornisce il risultato finale, che poi utilizziamo in qualche modo (ripristiniamo, ripetiamo, analizziamo, ammiriamo). Svantaggi: il processo risulta piuttosto complesso e, inoltre, manca un'interfaccia per il personale operativo.<\/p>\n
<\/p>\n
Alla fine ci siamo comunque fermati sulla seconda opzione. Per le estrazioni da diverse banche abbiamo utilizzato Apache Spark.<\/b> Il funzionamento del meccanismo si basa su codice Java che, utilizzando le chiavi specificate (abbonato, ora della chiamata \u2013 chiavi della sezione), estrae i dati da C*, insieme ai dati necessari per l'arricchimento da qualsiasi altro database. Successivamente, li unisce in memoria e restituisce il risultato in una tabella finale. Sopra Spark \u00e8 stata creata un'interfaccia web, rendendola pienamente utilizzabile.<\/p>\n
\n
Nella risoluzione del problema di aggiornamento dei dati, il team di prom-test ha nuovamente esaminato diversi metodi. Sia il trasferimento tramite Sstloader, sia la divisione del cluster nella zona di test in due parti, ciascuna delle quali entra alternativamente in un cluster con quello di produzione, alimentandosi da esso. Durante l'aggiornamento del test, era previsto che le parti cambiassero posto: quella che lavorava nel test veniva pulita e introdotta in produzione, mentre l'altra iniziava a lavorare con i dati separatamente. Tuttavia, riflettendo ulteriormente, abbiamo valutato in modo pi\u00f9 razionale i dati da trasferire e abbiamo compreso che le stesse chiamate sono un'entit\u00e0 inconsistenti per i test, generate rapidamente in caso di necessit\u00e0, e che proprio il set di dati di produzione non ha valore per il trasferimento nel test. Ci sono diversi oggetti di accumulo che vale la pena trasferire, ma si tratta di letteralmente un paio di tabelle, e non molto pesanti. Pertanto, ci \u00e8 venuto nuovamente in aiuto Spark, con il quale abbiamo scritto e iniziato a utilizzare attivamente uno script di trasferimento dei dati tra le tabelle di produzione e test.<\/b><\/p>\n
<\/p>\n
La nostra attuale politica di deploy ci consente di operare senza rollback.<\/b> Prima di ogni promozione, \u00e8 necessario un test preliminare, dove un errore ha un costo contenuto. In caso di fallimento, \u00e8 sempre possibile ripristinare il case space e ricominciare da capo con l'intera configurazione.<\/p>\n
<\/p>\n
Per garantire la disponibilit\u00e0 continua di Cassandra, \u00e8 necessario un DBA e non solo lui. Tutti coloro che lavorano con l'applicazione devono comprendere dove e come monitorare la situazione attuale e diagnosticare tempestivamente eventuali problemi.<\/b> A tal fine, utilizziamo attivamente DataStax OpsCenter (gestione e monitoraggio dei carichi di lavoro), metriche di sistema del Cassandra Driver (numero di timeout in scrittura in C*, numero di timeout in lettura da C*, latenza massima, ecc.), e monitoriamo il funzionamento stesso dell'applicazione che interagisce con Cassandra.\n<\/p>\n
<\/p>\n
Quando abbiamo riflettuto sulla domanda precedente, ci siamo resi conto di dove potrebbe trovarsi il principale rischio. Si tratta delle modalit\u00e0 di visualizzazione dei dati che estraggono informazioni da pi\u00f9 query indipendenti tra loro. In questo modo, potremmo ottenere informazioni piuttosto incoerenti. Tuttavia, questo problema sarebbe altrettanto pertinente anche se lavorassimo con un solo data center. Pertanto, la cosa pi\u00f9 sensata da fare \u00e8, ovviamente, implementare una funzione batch per la lettura dei dati in un'applicazione esterna, che garantisca l'ottenimento dei dati in un unico intervallo di tempo. Per quanto riguarda la separazione tra lettura e scrittura in termini di prestazioni, qui ci ha frenato il rischio che, in caso di una certa perdita di connessione tra i data center, potremmo ricevere due cluster completamente incoerenti tra loro.<\/p>\n
<\/p>\n
Di conseguenza, al momento ci siamo fermati a un livello di coerenza per la scrittura di EACH_QUORUM, per la lettura \u2013 LOCAL_QUORUM<\/b><\/p>\n
<\/p>\n
Impressioni e conclusioni sintetiche<\/h2>\n <\/p>\n
Per valutare la soluzione ottenuta in termini di supporto operativo e prospettive di ulteriore sviluppo, abbiamo deciso di riflettere su dove altro potrebbe essere applicato questo sviluppo.<\/p>\n
<\/p>\n
Se parliamo subito, il punteggio dei dati per programmi come \"Paga quando vuoi\" (caricando informazioni in S*, calcolo tramite script Spark), la gestione dei reclami con aggregazione per direzioni, la memorizzazione dei ruoli e il calcolo in base alla matrice dei diritti di accesso degli utenti. <\/p>\n
<\/p>\n
Come possiamo notare, il repertorio \u00e8 ampio e variegato. E se dobbiamo scegliere da che parte schierarci, tra sostenitori e avversari di NoSQL, ci uniremo ai sostenitori, dato che ne abbiamo ricevuto beneficit\u00e0, precisamente dove ce lo aspettavamo.<\/p>\n
<\/p>\n
Anche la versione di Cassandra out-of-the-box consente la scalabilit\u00e0 orizzontale in tempo reale, risolvendo senza problemi la questione dell'aumento dei dati nel sistema. Siamo riusciti a separare in un contesto distinto un meccanismo ad alta intensit\u00e0 di carico per il calcolo degli aggregati delle chiamate, e a separare lo schema e la logica dell'applicazione, liberandoci dalla cattiva prassi di scrivere job e oggetti personalizzati direttamente nel database. Abbiamo ottenuto la possibilit\u00e0 di scegliere e configurare, per ottimizzare, in quali data center eseguiremo il calcolo e in quali scriveremo i dati, mettendo in protezione i nostri interessi in caso di guasti sia di singoli nodi che dell'intero data center.<\/p>\n
<\/p>\n
Applicando la nostra architettura ai nuovi progetti, e avendo gi\u00e0 un'esperienza preliminare, \u00e8 fondamentale considerare fin da subito le peculiarit\u00e0 descritte sopra, evitando alcuni errori e smussando gli angoli pi\u00f9 spigolosi che inizialmente non siamo riusciti a evitare.<\/p>\n
<\/p>\n
Ad esempio, monitorare tempestivamente gli aggiornamenti di Cassandra<\/b>, poich\u00e9 molte delle problematiche riscontrate erano gi\u00e0 note e sono state corrette.<\/p>\n
<\/p>\n
Evitare di posizionare sia il database che Spark sulle stesse nodi<\/b> (o separare rigorosamente in base alla capacit\u00e0 massima delle risorse utilizzate), poich\u00e9 Spark pu\u00f2 utilizzare pi\u00f9 RAM di quanto previsto, e questo porter\u00e0 rapidamente al problema numero 1 della nostra lista.<\/p>\n
<\/p>\n
Potenziare il monitoraggio e le competenze operative gi\u00e0 nella fase di test del progetto. <\/b>Considerare sin dall'inizio tutti i potenziali utenti della nostra soluzione<\/b>, poich\u00e9 la struttura del database dipender\u00e0 in ultima analisi proprio da questo.<\/p>\n
<\/p>\n
Esaminare pi\u00f9 volte il diagramma risultante per possibili ottimizzazioni. Identificare quali campi possono essere serializzati. Comprendere quali tabelle aggiuntive dobbiamo creare per tenere conto in modo pi\u00f9 accurato ed ottimale e per fornire successivamente le informazioni richieste (ad esempio, tenendo presente che possiamo conservare gli stessi dati in tabelle diverse, a seconda di diversi criteri, possiamo risparmiare notevolmente tempo di CPU durante le query di lettura).<\/p>\n
<\/p>\n
Non male prevedere subito l'assegnazione di TTL e la pulizia dei dati obsoleti.<\/b><\/p>\n
<\/p>\n
Durante l'esportazione dei dati da Cassandra la logica dell'applicazione deve funzionare secondo il principio FETCH, per evitare che tutte le righe siano caricate in memoria contemporaneamente, ma selezionate a pacchetti.<\/b><\/p>\n
<\/p>\n
\u00c8 consigliabile verificare la tolleranza ai guasti del sistema, eseguendo una serie di crash test prima di trasferire il progetto alla soluzione descritta. verifica la resilienza del sistema eseguendo una serie di crash test<\/b>, come la perdita di dati in un datacenter, il ripristino di dati danneggiati in un certo periodo, problemi di rete tra i datacenter. Questi test non solo permetteranno di valutare i pro e i contro dell'architettura proposta, ma daranno anche una buona opportunit\u00e0 di pratica ai tecnici che li eseguiranno, e le competenze acquisite non saranno affatto superflue nel caso di malfunzionamenti del sistema.<\/p>\n
<\/p>\n
Se lavoriamo con informazioni critiche (come i dati per la fatturazione, il calcolo dei debiti degli abbonati), \u00e8 importante prestare attenzione agli strumenti che possono contribuire a ridurre i rischi derivanti dalle peculiarit\u00e0 del DBMS. Ad esempio, utilizzare l'utilit\u00e0 nodesync (Datastax), sviluppando una strategia ottimale per il suo utilizzo, affinch\u00e9 per garantire coerenza non si crei un carico eccessivo su Cassandra.<\/b> e utilizzarla solo per determinate tabelle in determinati periodi.<\/p>\n
<\/p>\n
Beh, dopo sei mesi di utilizzo con Cassandra? In generale, non ci sono problemi irrisolti. Non abbiamo nemmeno avuto seri incidenti o perdite di dati. S\u00ec, abbiamo dovuto riflettere su come compensare alcuni problemi che non si erano mai presentati prima, ma alla fine questo non ha particolarmente offuscato la nostra soluzione architettonica. Se siete pronti e non temete di provare qualcosa di nuovo, e al contempo non volete rimanere troppo delusi, preparatevi al fatto che nulla \u00e8 davvero gratuito. Dovrete impegnarvi, approfondire la documentazione e costruire i vostri specifici ostacoli pi\u00f9 del necessario rispetto a una vecchia soluzione legacy, e nessuna teoria vi potr\u00e0 anticipare quali ostacoli vi attendono.<\/p>\n
Fonte: 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
![\"Come](\"\/wp-content\/uploads\/2019\/08\/4845d37a9928f888639c4ebeb7807787.jpg\")
![\"Come](\"\/wp-content\/uploads\/2019\/08\/c7b095dc8879011adb751c96427af512.jpg\")
<\/p>\n