<\/a><\/noindex><\/p>\nQuindi, ecco cosa ci ha insegnato l'esperienza.<\/h2>\n <\/p>\n
S\u00ec, una nodo che va gi\u00f9 non \u00e8 una tragedia. Questo \u00e8 il punto della tolleranza ai guasti di Cassandra. Ma una nodo pu\u00f2 essere attiva e allo stesso tempo iniziare a calare in termini di prestazioni.<\/b>Come si \u00e8 scoperto, questo si riflette immediatamente sulle prestazioni dell'intero cluster.<\/p>\n
<\/p>\n
Cassandra non offre le stesse garanzie di Oracle con i suoi vincoli.<\/b>E se l'autore dell'applicazione non lo ha capito in anticipo, un duplicato che arriva per Cassandra non \u00e8 affatto inferiore all'originale. Se \u00e8 arrivato, lo inseriamo.<\/p>\n
<\/p>\n
La versione gratuita di Cassandra 'out of the box' non \u00e8 piaciuta ai professionisti della sicurezza: non ci sono registrazioni delle azioni degli utenti, n\u00e9 limitazioni dei diritti.<\/b>. Le informazioni sulle chiamate riguardano i dati personali, il che significa che ogni tentativo di richiederli o modificarli deve essere registrato con la possibilit\u00e0 di audit successivi. Inoltre, \u00e8 necessario essere consapevoli della necessit\u00e0 di separare i diritti a diversi livelli per diversi utenti. Un semplice ingegnere operativo e un super amministratore, che pu\u00f2 liberamente eliminare l'intero keyspace, sono ruoli diversi, con responsabilit\u00e0 e competenze diverse. Senza 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 \u00e8 necessaria sia un'analisi seria che campionamenti periodici in base a vari criteri. Poich\u00e9 i record selezionati devono poi essere eliminati e riscritti (nell'ambito del compito dobbiamo supportare il processo di aggiornamento dei dati in seguito a dati inizialmente errati che ci sono stati forniti), Cassandra non \u00e8 qui un alleato. Cassandra, come una cassaforte, \u00e8 comoda per accumulare dati, ma non riesce a fare calcoli.<\/b><\/p>\n
<\/p>\n
Ci siamo imbattuti in un problema di migrazione dei dati nelle aree di test.<\/b> (5 nodi nel test contro 20 in produzione). In tal caso non sar\u00e0 possibile utilizzare il dump.<\/p>\n
<\/p>\n
Problema degli aggiornamenti dello schema dei dati dell'applicazione che scrive su Cassandra. Il rollback generer\u00e0 un gran numero di tombstone, il che potrebbe in modo imprevedibile influire sulle prestazioni.<\/b>. Cassandra \u00e8 ottimizzata per la scrittura e, prima di scrivere, non pensa molto. Qualsiasi operazione sui dati esistenti in essa \u00e8 anch'essa una scrittura. Cio\u00e8, eliminando il superfluo, generiamo solo un numero maggiore di scritture, e solo una parte di esse sar\u00e0 contrassegnata come tombstone.<\/p>\n
<\/p>\n
Timeout durante l'inserimento. Cassandra \u00e8 ottima per la scrittura, ma a volte il flusso in ingresso pu\u00f2 confonderla significativamente.<\/b>. Questo accade quando l'applicazione inizia a ciclare su diversi record che non possono essere inseriti per qualche motivo. E avremo bisogno di un DBA vero e proprio, che controlli gc.log, i log system e debug per query lente, e le metriche di compaction pending.\n<\/p>\n
<\/p>\n
Diverse aree geografiche nel cluster. Da dove leggere e dove scrivere?<\/b>
<\/p>\n
Come abbiamo risolto<\/h2>\n <\/p>\n
Per evitare che il nodo si bloccasse, abbiamo disattivato il SWAP<\/b>. E ora, in caso di mancanza di memoria, il nodo dovrebbe cadere, piuttosto che generare lunghe pause di garbage collection.<\/p>\n
<\/p>\n
Quindi, non ci aspettiamo pi\u00f9 logica nel database. Gli sviluppatori dell'applicazione stanno riqualificando e cominciano a proteggere attivamente il proprio codice.<\/b> Un perfetto e chiaro separazione tra archiviazione e trattamento dei dati.<\/p>\n
<\/p>\n
Abbiamo acquistato supporto da DataStax.<\/b> La versione box di Cassandra non \u00e8 pi\u00f9 sviluppata (l'ultimo commit \u00e8 stato nel febbraio 2018). Nel frattempo, DataStax offre un ottimo servizio e un'ampia gamma di soluzioni migliorate e adattate ai sistemi esistenti.<\/p>\n
<\/p>\n
Voglio anche sottolineare che Cassandra non \u00e8 molto pratica per le query di selezione. Ovviamente, CQL rappresenta un grande passo avanti per gli utenti (rispetto a Thrift). Ma se avete interi reparti abituati a giunture cos\u00ec comode, a una filtrazione libera su qualsiasi campo e a opportunit\u00e0 di ottimizzazione delle query, la soluzione basata su Cassandra appare per loro ostile e illogica. E abbiamo iniziato a risolvere il problema su come far eseguire le selezioni ai nostri colleghi. <\/p>\n
<\/p>\n
Abbiamo considerato due opzioni. Nella prima opzione scriviamo le chiamate non solo in C*, ma anche nel database archiviato Oracle. Solo che, a differenza di C*, in questo database sono memorizzate solo le chiamate dell'attuale mese (profonit\u00e0 di memorizzazione sufficiente per i casi di riconfigurazione). Qui emerge subito il problema successivo: se scriviamo in modo sincrono, perdiamo tutti i vantaggi di C* riguardanti l'inserimento rapido; se in modo asincrono, non abbiamo garanzie che tutte le chiamate necessarie siano effettivamente arrivate in Oracle. C'era un vantaggio, ma grande: per l'uso rimane sempre il consueto PL\/SQL Developer, quindi praticamente realizziamo il pattern 'Facciata'. Opzione alternativa. Implementiamo un meccanismo che estrae le chiamate da C*, recupera alcuni dati per arricchire da tabelle corrispondenti in Oracle, unisce i risultati ottenuti e ci fornisce il risultato ottenuto, che poi utilizziamo in qualche modo (annulliamo, ripetiamo, analizziamo, ammiriamo). Gli svantaggi: il processo risulta piuttosto a pi\u00f9 fasi, e inoltre, non c'\u00e8 un'interfaccia per il personale operativo.<\/p>\n
<\/p>\n
Alla fine, ci siamo comunque fermati sulla seconda opzione. Per le estrazioni da diversi database abbiamo utilizzato Apache Spark.<\/b> Essenza del meccanismo si \u00e8 ridotta a codice Java, che estrae i dati da C* in base alle chiavi specificate (abbonato, ora della chiamata - chiavi della sezione) e i dati necessari per l'arricchimento da qualsiasi altro database. Dopodich\u00e9, li unisce nella propria memoria e restituisce il risultato nella tabella dei risultati. Abbiamo creato un'interfaccia web sopra Spark che \u00e8 risultata abbastanza utilizzabile.<\/p>\n
\n
Nel risolvere il compito di aggiornamento dei dati, il team di prom-test ha nuovamente esaminato diverse opzioni. Sia la migrazione tramite Sstloader che la possibilit\u00e0 di suddividere il cluster nell'area di test in due parti, ciascuna delle quali viene alternata in un cluster con quello di prom, alimentandosi cos\u00ec da esso. Durante l'aggiornamento del test, era previsto il cambio di posto: la parte che lavorava nel test veniva pulita e immessa in prom, mentre l'altra iniziava a lavorare con i dati separatamente. Tuttavia, dopo aver riflettuto di nuovo, abbiamo valutato in modo pi\u00f9 razionale quali dati valesse la pena trasferire e abbiamo capito che le chiamate di per s\u00e9 sono un'entit\u00e0 non consistente per i test, rapidamente generata in caso di necessit\u00e0, e che il set di dati di prom non ha valore per il trasferimento nel test. Ci sono diversi oggetti-accumulatori che vale la pena trasferire, ma sono letteralmente un paio di tabelle, non troppo pesanti. Pertanto, noi come soluzione, \u00e8 tornato in aiuto Spark, grazie al quale abbiamo scritto e iniziato a utilizzare attivamente uno script per il trasferimento dei dati tra le tabelle prom-test.<\/b><\/p>\n
<\/p>\n
La nostra attuale politica di deployment ci consente di lavorare senza rollback.<\/b> Prima di prom, \u00e8 previsto un obbligatorio caricamento su test, dove l'errore non \u00e8 cos\u00ec costoso. In caso di fallimento, \u00e8 sempre possibile eliminare il case space e ricaricare l'intero schema dall'inizio.<\/p>\n
<\/p>\n
Per garantire la disponibilit\u00e0 continua di Cassandra \u00e8 necessaria una DBA e non solo. Tutti coloro che lavorano con l'applicazione devono capire dove e come osservare la situazione corrente e come diagnosticare tempestivamente i problemi.<\/b> Per questo motivo utilizziamo attivamente DataStax OpsCenter (Amministrazione e monitoraggio dei carichi di lavoro), metriche di sistema del driver Cassandra (numero di timeout in scrittura in C*, numero di timeout in lettura da C*, latenza massima, ecc.), monitoriamo il funzionamento dell'applicazione stessa che lavora con Cassandra.\n<\/p>\n
<\/p>\n
Quando abbiamo considerato la domanda precedente, abbiamo capito dove potrebbe risiedere il rischio principale. Si tratta delle forme di visualizzazione dei dati che estraggono informazioni da pi\u00f9 richieste indipendenti l'una dall'altra verso il data store. In questo modo, potremmo ottenere informazioni piuttosto incoerenti. Ma questo problema sarebbe stato altrettanto rilevante anche se avessimo lavorato solo con un data center. Quindi, la cosa pi\u00f9 sensata da fare qui \u00e8, naturalmente, creare una funzione di lettura dei dati batch su un'applicazione esterna, che garantisca il recupero dei dati in un unico intervallo di tempo. Per quanto riguarda la divisione tra lettura e scrittura in termini di prestazioni, ci ha fermati il rischio che, in caso di perdita di connessione tra i DC, potremmo ottenere due cluster totalmente incoerenti tra loro.<\/p>\n
<\/p>\n
Alla fine, attualmente 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 brevi<\/h2>\n <\/p>\n
Per valutare la soluzione ottenuta dal punto di vista del supporto operativo e delle prospettive di sviluppo futuro, abbiamo deciso di riflettere su dove poter applicare ulteriormente tale sviluppo.<\/p>\n
<\/p>\n
Se dovessi pensare in modo immediato, il punteggio dei dati per programmi come \"Paga quando ti \u00e8 comodo\" (carichiamo in S* informazioni, calcolo su script Spark), gestione delle contestazioni con aggregazione per direzione, memorizzazione dei ruoli e calcolo secondo la matrice dei diritti di accesso degli utenti. <\/p>\n
<\/p>\n
Come vediamo, il repertorio \u00e8 ampio e vario. E se dovessimo scegliere il campo tra sostenitori e oppositori di NoSQL, ci uniremo ai sostenitori, poich\u00e9 abbiamo ottenuto i nostri vantaggi, proprio l\u00ec dove ci aspettavamo.<\/p>\n
<\/p>\n
Anche la versione di Cassandra out-of-the-box consente di effettuare scalabilit\u00e0 orizzontale in tempo reale, risolvendo in modo assolutamente indolore la questione dell'aumento dei dati nel sistema. Siamo riusciti a portare in un contesto separato un meccanismo ad alta intensit\u00e0 di carico per il calcolo degli aggregati sulle chiamate, e a separare schema e logica dell'applicazione, liberandoci dalla cattiva pratica di scrivere job personalizzati e oggetti nel database stesso. Abbiamo ottenuto la possibilit\u00e0 di scegliere e configurare, per accelerare, in quali DC eseguire il calcolo e in quali inserire i dati, mettendoci al riparo da possibili cadute di singoli nodi, cos\u00ec come in generale del DC.<\/p>\n
<\/p>\n
Applicando la nostra architettura ai nuovi progetti, e avendo gi\u00e0 qualche esperienza, vorremmo subito tenere conto delle sfumature descritte sopra e non commettere alcuni errori, smussare alcuni angoli acuti che non siamo riusciti ad evitare inizialmente.<\/p>\n
<\/p>\n
Ad esempio, monitorare tempestivamente gli aggiornamenti della stessa Cassandra<\/b>, poich\u00e9 molti dei problemi che abbiamo affrontato erano gi\u00e0 noti e sono stati corretti.<\/p>\n
<\/p>\n
Non installare sia il DB che Spark sugli stessi nodi<\/b> (o separare rigorosamente in base alla quantit\u00e0 consentita di utilizzo delle risorse), poich\u00e9 Spark potrebbe consumare pi\u00f9 RAM del consentito e potremmo rapidamente incontrare il 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 fin da subito tutti i potenziali consumatori della nostra soluzione<\/b>, poich\u00e9 la struttura del DB alla fine dipender\u00e0 proprio da questo.<\/p>\n
<\/p>\n
Rivedere pi\u00f9 volte lo schema risultante per identificarne le possibili ottimizzazioni. Avere chiaro quali campi \u00e8 possibile serializzare. Comprendere quali tabelle aggiuntive dobbiamo creare per considerare e restituire in modo corretto e ottimale le informazioni richieste (ad esempio, considerando che gli stessi dati possono essere memorizzati in diverse tabelle, tenendo conto di suddivisioni differenti in base a vari criteri, possiamo risparmiare notevolmente tempo della CPU durante le richieste di lettura).<\/p>\n
<\/p>\n
Bene prevedere fin da subito l'aggiunta 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, in modo che non tutte le righe vengano caricate in memoria in una sola volta, ma vengano selezionate a blocchi.<\/b><\/p>\n
<\/p>\n
\u00c8 preferibile verificare la resilienza del sistema prima di passare al sistema descritto effettuando una serie di test di crash<\/b>, come la perdita di dati in un data center, il ripristino di dati danneggiati su un certo periodo, e il degrado della rete tra i data center. Tali test non solo consentiranno di valutare i pro e i contro dell'architettura proposta, ma forniranno anche una buona pratica per ingegneri che li eseguono, e le competenze acquisite non saranno affatto superflue in caso di guasti del sistema che si verifichino in produzione.<\/p>\n
<\/p>\n
Se lavoriamo con informazioni critiche (come dati per la fatturazione, calcolo del debito del cliente), \u00e8 importante prestare attenzione agli strumenti che possono ridurre i rischi derivanti dalle peculiarit\u00e0 del DBMS. Ad esempio, utilizzare l'utility nodesync (Datastax) sviluppando una strategia ottimale per il suo utilizzo, in modo da non generare un carico eccessivo su Cassandra per garantire la consistenza<\/b> e utilizzarla solo per determinate tabelle in determinati periodi.<\/p>\n
<\/p>\n
E cos\u00ec, dopo sei mesi di esperienza con Cassandra? In generale, non ci sono problemi irrisolti. Non abbiamo avuto gravi guasti o perdite di dati. S\u00ec, abbiamo dovuto riflettere sulla compensazione di alcuni problemi che non si erano mai verificati prima, ma alla fine questo non ha in alcun modo influenzato la nostra soluzione architettonica. Se vuoi e non temi di provare qualcosa di nuovo, e non vuoi deluderti troppo, preparati al fatto che nulla \u00e8 gratis. Dovrai dedicarti a studiare, approfondire la documentazione e costruire le tue<\/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