Raggiungere scalabilità e ACID con una soluzione di streaming RDBMS to NoSQL

Question

Raggiungere scalabilità e ACID con una soluzione di streaming RDBMS to NoSQL

#1 da (1 voti)

5

La mia comprensione è che la caratteristica principale che Cassandra ha da offrire è prestazione lineare a qualsiasi scala ; significa che se so che il nodo 1 C * è in grado di gestire 500 query o comandi al secondo dalla mia app, allora posso anche essere certo che 100 nodi C * aggiunti allo stesso cluster saranno in grado di gestire query o comandi 500 * 100 = 50K al secondo.

La mia comprensione del compromesso principale tra RDBMS e NoSQL è che i sistemi NoSQL tendono a favorire la scalabilità, ma che richiede loro (meccanicamente, a causa dell'implementazione) il bisogno di rilassare la loro transabilità. Quindi i sistemi NoSQL come C * generalmente scalano estremamente bene, ma non sono in grado di offrire le classiche transazioni ACID che i sistemi RDBMS come MySQL possono.

La mia comprensione è che dal momento che scalabilità e transabilità si escludono a vicenda l'una dall'altra, non ci sono database magici NoSQL che offrono scalabilità C * -like (di nuovo: prestazioni lineari a qualsiasi scala) e che offrono client Java con JTA implementate (capacità di commit + rollback) in essi.

Queste sono le mie assunzioni in questa domanda: se ho sbagliato o sbagliato su qualcuno di loro, per favore inizia correggendomi!

Supponendo che io sia più o meno corretto in tutte queste ipotesi, allora cosa si fa quando si ha effettivamente bisogno di transazioni di scalabilità e ACID? La mia unica idea qui sarebbe implementare quanto segue:

Configura l'app per scrivere su un RDBMS (come MySQL) utilizzando un driver compatibile con JDBC / JTA (ad esempio utilizzando le transazioni)
In qualche modo , configura l'RDBMS per replicare (in tempo reale o con latenza molto bassa) in un DB altamente scalabile (come Cassandra). Questa potrebbe essere un'opzione di configurazione che il RDBMS stesso offre, o molto più probabilmente, sarà il codice di cui hai bisogno per scrivere te stesso continuamente su ETL da un sistema all'altro. L'idea qui è che l'app dovrebbe leggere dalla tabella NoSQL e avere comunque letture molto performanti rispetto a una quantità enorme di dati.
In qualche modo configura le tabelle RDBMS con TTL in modo che le tabelle non diventino estremamente grandi e inizino a richiedere sharding e altri trucchi che possono rallentare le transazioni. Anche in questo caso, questa potrebbe essere un'opzione di configurazione offerta dallo stesso RDBMS oppure è probabile che il codice sia necessario per scrivere da solo.

Esistono soluzioni meglio conosciute qui? Qualsiasi insidia / caveat a questo approccio?

java nosql transaction cassandra jdbc

posta hotmeatballsoup 06.07.2018 - 18:00

fonte

1 risposta

Leggi altre domande sui tag java nosql transaction cassandra jdbc

Programmazione funzionale: scrivere un piccolo interprete Come districare una classe di dati in cui si mescolano le annotazioni di diversi framework?

score 1 · Accepted Answer

Le tue ipotesi non sono tanto sbagliate quanto incomplete. Il compromesso tra scalabilità (tollerare partizioni di rete o P in CAP) e transabilità (coerenza o C in CAP) non si pone a livello di un sistema ma a livello di una singola operazione o transazione. Vale a dire, una transazione può essere coerente o può sfruttare la scala orizzontale, ma non entrambe. I database sono tuttavia liberi di fornire entrambi i meccanismi. Ad esempio, cassandra supporta le transazioni leggere e le letture / scritture di maggioranza che forniscono meccanismi per garantire la coerenza.

L'immagine diventa ancora più complicata perché si tratta di proprietà tecniche, ma non si comportano esattamente come ci si aspetterebbe intuitivamente. Ad esempio, la chiave del cloud di Google offre scalabilità e coerenza consistente dal punto di vista dell'utente del database , anche se internamente è alla fine coerente. Sharding è un modo per imbrogliare , con il sistema nel suo complesso che sfrutta la scala orizzontale ma tutti i dati all'interno di un frammento sono strongmente coerenti.

Ora, per la tua domanda su come raggiungere la coerenza e della scalabilità, alcune strategie:

Il problema si pone solo nei casi in cui è necessario leggere prima di scrivere. Puoi provare ad isolare quelle parti che rientrano in quella categoria e utilizzare un meccanismo o un database diverso per servirle. L'applicazione di sharding può aiutare a suddividere ulteriormente il set di dati coerenti per adattarsi all'interno di un server.
Puoi trarre vantaggio dal fatto che probabilmente non tutte le letture devono avere una vista coerente e utilizzare le cache o le query non ACID (ad esempio, cassandra read consistency ONE).
Nei casi in cui si desidera sostituire un grafico complesso di dati con un nuovo complesso grafico di dati che deve essere del tutto coerente, è possibile utilizzare una strategia di controllo delle versioni in cui si scrive la nuova versione del grafico utilizzando scritture non atomiche e quindi passa a quella versione con una scrittura atomica.