•  18-09-2019
  •  | 
  •  

Domanda

sto cercando in NoSQL per scalare le alternative a un database. Cosa devo fare se voglio le cose basate sulle transazioni che sono sensibili a questo genere di cose?

È stato utile?

Soluzione

In linea generale, le soluzioni NoSQL hanno un peso più leggero semantica transazionale di database relazionali, ma hanno ancora strutture per le operazioni atomiche a un certo livello.

In generale, quelli che fanno la replicazione master-master forniscono meno in termini di coerenza, e più disponibilità. Quindi, si dovrebbe scegliere lo strumento giusto per il problema a destra.

Molte transazioni d'offerta alla singolo documento (o riga, ecc) livello. Ad esempio, con MongoDB c'è atomicity al singolo documento - ma i documenti può essere abbastanza ricca quindi questo di solito funziona abbastanza bene - maggiori informazioni qui .

Altri suggerimenti

Questa è la risposta più vicina che ho trovato che si applicherebbe a qualsiasi database NoSQL. E 'un post del blog 2007 da Adamo Wiggins di Heroku.com:

  

L'antico esempio di utilizzo di una transazione di database per avvolgere il trasferimento di denaro da un conto bancario ad un altro è toro totale. La soluzione corretta è per memorizzare un elenco di eventi contabili (trasferimenti fra conti) e mostra il saldo attuale come somma del libro mastro. Se si sta programmando in un linguaggio funzionale (o pensare in questo modo), questo è ovvio.

Da: http://adam.heroku.com/past/2007 / 12/17 / a_world_without_sql / (Il suo sito web è grande per le idee su scalabilità.)

ho interpretato il paragrafo precedente come:

  1. Creare un database per gli account membri.
  2. Creare una coda di messaggistica. Soprannome che "libro mastro".
  3. Aggiungi in fondo lavoratori per soddisfare ogni richiesta in coda.

Più informazioni. sulle code / sfondo lavoratori: http://adam.heroku.com/past/ 2009/4 / 14 / building_a_queuebacked_feed_reader_part_1 /

Il client (aka utente o cliente) segue questi passaggi per prendere i soldi:

  1. Invia una richiesta di prendere i soldi.
  2. richiesta viene inviata al server.
  3. Server lo colloca in una coda. Il messaggio è: "Prendere fuori $ 5.000"
  4. Client viene mostrato: "Attendere come richiesta sta per essere soddisfatta ..."
  5. macchine client sondaggi server ogni 2 secondi che chiedono, "ha la richiesta di stati rispettati?"
  6. Il server sfondo lavoratori stanno adempiendo le richieste precedenti da altri membri in first-in / first-out di moda. Alla fine, si arriva a richiesta del cliente a prendere i soldi.
  7. Una volta richiesta è stata soddisfatta, cliente viene dato un messaggio con il loro nuovo equilibrio.

È possibile utilizzare Heroku.com per creare un piccolo mock-up rapidamente se hai dimestichezza con Node.js o Ruby / cremagliera.

L'idea generale sembra abbastanza facile e molto meglio che usare le transazioni da forno nel database che lo rendono super-difficile da scalare.

Avviso: non ho ancora implementato questa in alcun modo. Ho letto di queste cose per curiosità, anche se non ho alcun bisogno pratico per loro. Sì, @gbn è giusto che un RDBMS con transazioni sarebbe probabilmente sufficiente per le esigenze di Timmy e me. Tuttavia, sarebbe stato divertente vedere quanto lontano si può prendere i database NoSQL con strumenti open-source ed un how-to sito web chiamato " Un tornado di Razorblades ".

NoSQL copre un insieme diversificato di strumenti e servizi, tra cui chiave-a valore, documenti , grafico e largo colonne negozi. Di solito provare a migliorare la scalabilità dei data store, di solito distribuendo l'elaborazione dei dati. Le operazioni richiedono proprietà ACID di come DB eseguono le operazioni dell'utente. ACIDO restringe come la scalabilità può essere migliorata: la maggior parte degli strumenti di NoSQL rilassarsi criteri di coerenza delle operatioins per ottenere tolleranza ai guasti e la disponibilità per il ridimensionamento, il che rende attuazione transazioni ACID molto difficile.

A comunemente citato ragionamento teorico di file system distribuito è il href="http://en.wikipedia.org/wiki/CAP_theorem" teorema cap : consistenza, la disponibilità e la tolleranza partizione non può essere raggiunto, allo stesso tempo. strumenti di SQL, NoSQL e NewSQL possono essere classificati in base a quello che rinunciare; una bella figura potrebbe essere trovata qui .

Un nuovo, insieme più debole dei requisiti di sostituzione ACID è BASE ( "in fondo avalilable, morbido stato, eventuale consistenza "). Tuttavia, alla fine strumenti coerenti ( "alla fine tutti gli accessi a un elemento restituirà l'ultimo valore aggiornato") sono difficilmente accettabili nelle applicazioni transazionali come bancario. Ecco una buona idea sarebbe quella di utilizzare in-memory, colonna-oriented e distribuito SQL / database ACID, ad esempio VoltDB ; Suggerisco guardando queste soluzioni "NewSQL".

Volevo solo commentare i consigli transazione di denaro su questo thread. Le transazioni sono qualcosa che si vuole veramente utilizzare con trasferimenti di denaro.

L'esempio dato come si fa que i trasferimenti è molto bella e ordinata.

Ma nella vita reale il trasferimento di denaro possono includere tasse o pagamenti ad altri account. La gente ottiene bonus per l'utilizzo di alcune carte che provengono da un altro account o possono ottenere commissioni presi dal loro conto a un altro account nel sistema stesso. Le tasse o pagamenti può variare di transazione finanziaria e potrebbe essere necessario per tenere il passo sistema di contabilità che mostri di credito e di debito di ogni transazione come viene.

Questo significa che si desidera aggiornare più di una riga nello stesso tempo dal credito su un account può essere addebito su uno o più account. Prima di bloccare le righe in modo nulla può cambiare prima di aggiornamento quindi garantirà che i dati scritti è coerente con la transazione.

È per questo che si vuole veramente utilizzare le transazioni. Se qualcosa va storto la scrittura di una riga è possibile far ritirare tutta una serie di aggiornamenti, senza i dati relativi alle transazioni finanziarie che terminano incoerente.

Il problema con una transazione e due operazioni (per esempio una pagare $ 5.000, secondo riceverà $ 5.000) - è che si hanno due account con stessa priorità. Non è possibile utilizzare un unico account per confermare seconda (o in ordine inverso). In questo caso si può garantire solo un account sarà corretto (che è confermato), secondo (che conferma) possono avere esito negativo. Vediamo perché può mancare (usando il messaggio aproatch, il mittente è confermata da ricevitore):

  1. Scrivi + $ 5.000 a della ricevente conto
  2. Se il successo - scrittura - $ 5.000 a conto del mittente
  3. Se fallisce - provare againt o annullare o mostrare un messaggio

Sarà garanzia salvare per 1 #. Ma chi garanzia se # 2 non riesce? Lo stesso vale per l'ordine inverso.

Ma questo è possibile implementa per essere sicuro senza transazioni e con NoSQL. Sei sempre consentito l'uso terza entità che sarà confermata dal mittente e destinatario e di garanzia l'operazione è stata eseguita:

  1. Generazione unica transazione id e la creazione di entità delle transazioni
  2. Scrivi + $ 5.000 a della ricevente conto (con riferimento alla transazione id)
  3. Se il successo - impostare lo stato della transazione per l'invio
  4. Scrivi - $ 5.000 a sedned conto conto (con riferimento alla transazione id)
  5. Se il successo - impostare lo stato della transazione per ricevere

Questo record operazione garanzia che si era ok per invio / ricezione di massaggi. Ora è possibile controllare ogni messaggio per transazione id e se ha stato ricevuto o completata - si prende in considerazione per l'equilibrio utente.

Dipende dal vostro DB, ma ... direi in generale, è possibile utilizzare «transazioni Ottimista ' per raggiungere questo obiettivo, ma immagino che si dovrebbe fare in modo di capire l'implementazione del database di atomicità garanzie (ad esempio, che tipo di operazioni di scrittura e lettura sono atomico).

Sembra che ci sia alcune discussioni in rete sulle transazioni HBase , se questo è di aiuto.

È sempre possibile utilizzare un approccio NoSQL in un DB SQL. NoSQL sembra utilizzare per genere "archivi di dati chiave / valore": è sempre possibile implementare questo nel vostro RDBMS preferite e quindi mantenere la roba buona come transazioni, proprietà ACID, supporto dal DBA amichevole, ecc, mentre realizzando i vantaggi di prestazioni e flessibilità NoSQL , per esempio tramite una tabella come 

CREATE TABLE MY_KEY_VALUE_DATA
(
    id_content INTEGER PRIMARY KEY,
    b_content  BLOB
);

Bonus è è possibile aggiungere campi aggiuntivi qui per collegare il tuo contenuto in altre tabelle, propriamente relazionali, pur mantenendo il vostro contenuto ingombrante nel BLOB principale (o TEXT se apt) campo.

Personalmente prediligo una rappresentazione di testo in modo che non siete legati in una lingua per lavorare con i dati, per esempio utilizzando serializzato Java significa che è possibile accedere al contenuto da Perl per la segnalazione, dicono. TESTO è anche più facile da mettere a punto e, in generale lavorare con come sviluppatore.

dare un'occhiata al suo scalaris un no db SQL con una forte coerenza e operazioni effettuate.

È per questo che sto creando una soluzione di document store NoSQL per essere in grado di utilizzare le transazioni "reali" sulle applicazioni Enterprise con la potenza di approccio dati non strutturati. Date un'occhiata a http://djondb.com e sentitevi liberi di aggiungere qualsiasi caratteristica si pensa possa essere utile.

sicuramente ci sono altri

È possibile implementare transazioni ottimistiche sulla sommità della soluzione NoSQL se supporta confrontare-e-set. Ho scritto un esempio e una spiegazione su un pagina GitHub come farlo in MongoDB, ma è possibile ripetere in qualsiasi soluzione adatta NoSQL.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top