So che ci sono domande simili qui, ma mi stanno dicendo di tornare ai normali sistemi RDBMS se ho bisogno di transazioni o uso operazioni atomiche o commit a due fasi . La seconda soluzione sembra la scelta migliore. Il terzo che non desidero seguire perché sembra che molte cose potrebbero andare storte e non posso provarlo in tutti gli aspetti. Sto facendo fatica a riformattare il mio progetto per eseguire operazioni atomiche. Non so se questo provenga dal mio punto di vista limitato (finora ho lavorato solo con i database SQL) o se in realtà non è possibile farlo.

Vorremmo testare MongoDB presso la nostra azienda. Abbiamo scelto un progetto relativamente semplice: un gateway SMS. Consente al nostro software di inviare messaggi SMS alla rete cellulare e il gateway fa il lavoro sporco: in realtà comunica con i provider tramite diversi protocolli di comunicazione. Il gateway gestisce anche la fatturazione dei messaggi. Ogni cliente che richiede il servizio deve acquistare alcuni crediti. Il sistema riduce automaticamente il saldo dell'utente quando viene inviato un messaggio e nega l'accesso se il saldo è insufficiente. Anche perché siamo clienti di fornitori di SMS di terze parti, potremmo anche avere i nostri saldi con loro. Dobbiamo tenere traccia anche di quelli.

Ho iniziato a pensare a come posso archiviare i dati richiesti con MongoDB se riduco la complessità (fatturazione esterna, invio di SMS in coda). Provenendo dal mondo SQL, vorrei creare una tabella separata per gli utenti, un'altra per i messaggi SMS e una per la memorizzazione delle transazioni relative al saldo degli utenti. Diciamo che creo raccolte separate per tutti quelli in MongoDB.

Immagina un'attività di invio di SMS con i seguenti passaggi in questo sistema semplificato:

1. controlla se l'utente ha un equilibrio sufficiente; negare l'accesso se non c'è credito sufficiente

2. inviare e archiviare il messaggio nella raccolta SMS con i dettagli e i costi (nel sistema live il messaggio avrebbe un statusattributo e un'attività lo prenderebbe per la consegna e fisserebbe il prezzo dell'SMS in base al suo stato attuale)

3. ridurre il saldo degli utenti in base al costo del messaggio inviato

4. registra la transazione nella raccolta delle transazioni

Ora qual è il problema con quello? MongoDB può eseguire aggiornamenti atomici su un solo documento. Nel flusso precedente potrebbe accadere che si verifichi un qualche tipo di errore e il messaggio venga archiviato nel database ma il saldo dell'utente non viene aggiornato e / o la transazione non viene registrata.

Ho avuto due idee:

• Crea una singola raccolta per gli utenti e archivia il saldo come campo, transazioni e messaggi relativi all'utente come documenti secondari nel documento dell'utente. Poiché siamo in grado di aggiornare i documenti atomicamente, questo risolve effettivamente il problema di transazione. Svantaggi: se l'utente invia molti messaggi SMS, la dimensione del documento potrebbe aumentare e il limite del documento di 4 MB potrebbe essere raggiunto. Forse posso creare documenti storici in tali scenari, ma non penso che sarebbe una buona idea. Inoltre, non so quanto veloce sarebbe il sistema se invii sempre più dati allo stesso grande documento.

• Crea una raccolta per gli utenti e una per le transazioni. Esistono due tipi di transazioni: acquisto di credito con cambio saldo positivo e messaggi inviati con cambio saldo negativo. La transazione può avere un documento secondario; ad esempio nei messaggi inviati i dettagli dell'SMS possono essere incorporati nella transazione. Svantaggi: non memorizzo il saldo utente corrente, quindi devo calcolarlo ogni volta che un utente tenta di inviare un messaggio per dire se il messaggio potrebbe passare o meno. Temo che questo calcolo possa rallentare con l'aumentare del numero di transazioni archiviate.

Sono un po 'confuso su quale metodo scegliere. Ci sono altre soluzioni? Non sono riuscito a trovare online le migliori pratiche su come aggirare questo tipo di problemi. Immagino che molti programmatori che stanno cercando di acquisire familiarità con il mondo NoSQL affrontino problemi simili all'inizio.

A partire da 4.0, MongoDB avrà transazioni ACID multi-documento. Il piano è di abilitare prima quelli nelle distribuzioni dei set di repliche, seguiti dai cluster frammentati. Le transazioni in MongoDB si sentiranno proprio come le transazioni con cui gli sviluppatori hanno familiarità con i database relazionali: saranno multiistruzione, con semantica e sintassi simili (come start_transactione commit_transaction). È importante sottolineare che le modifiche a MongoDB che abilitano le transazioni non influiscono sulle prestazioni dei carichi di lavoro che non le richiedono.

Per maggiori dettagli vedi qui .

Avere transazioni distribuite, non significa che dovresti modellare i tuoi dati come in database relazionali tabulari. Abbraccia la potenza del modello di documento e segui le buone e consigliate pratiche di modellazione dei dati.

Vivere senza transazioni

Le transazioni supportano le proprietà ACID ma sebbene non ci siano transazioni in MongoDB, abbiamo operazioni atomiche. Bene, le operazioni atomiche significano che quando lavori su un singolo documento quel lavoro verrà completato prima che qualcun altro veda il documento. Vedranno tutte le modifiche che abbiamo apportato o nessuna di esse. E usando le operazioni atomiche, spesso puoi realizzare la stessa cosa che avremmo realizzato usando le transazioni in un database relazionale. E la ragione è che, in un database relazionale, dobbiamo apportare modifiche su più tabelle. Di solito le tabelle che devono essere unite e quindi vogliamo farlo tutto in una volta. E per farlo, poiché ci sono più tabelle, dovremo iniziare una transazione e fare tutti quegli aggiornamenti e poi terminare la transazione. Ma conMongoDB, incorporeremo i dati, dal momento che li pre-uniremo ai documenti e sono questi ricchi documenti che hanno una gerarchia. Spesso possiamo realizzare la stessa cosa. Ad esempio, nell'esempio del blog, se volessimo assicurarci di aggiornare atomicamente un post sul blog, possiamo farlo perché possiamo aggiornare l'intero post sul blog in una sola volta. Dove come se fosse un gruppo di tabelle relazionali, probabilmente dovremmo aprire una transazione in modo da poter aggiornare la raccolta di post e la raccolta di commenti.

Quindi quali sono i nostri approcci che possiamo adottare MongoDBper superare la mancanza di transazioni?

• ristruttura - ristruttura il codice, in modo che stiamo lavorando all'interno di un singolo documento e sfruttando le operazioni atomiche che offriamo all'interno di quel documento. E se lo facciamo, allora di solito siamo pronti.
• implementare nel software : possiamo implementare il blocco nel software creando una sezione critica. Siamo in grado di costruire un test, testare e impostare usando trova e modifica. Possiamo costruire semafori, se necessario. E in un certo senso, è così che funziona il mondo più grande. Se ci pensiamo, se una banca ha bisogno di trasferire denaro a un'altra banca, non vivono nello stesso sistema relazionale. Ognuno di essi ha spesso i propri database relazionali. E devono essere in grado di coordinare tale operazione anche se non possiamo iniziare la transazione e terminare la transazione attraverso quei sistemi di database, solo all'interno di un sistema all'interno di una banca. Quindi ci sono certamente modi in cui il software aggira il problema.
• tollerare : l'approccio finale, che spesso funziona nelle moderne app Web e in altre applicazioni che raccolgono un'enorme quantità di dati, è solo tollerare un po 'di incoerenza. Un esempio sarebbe, se stiamo parlando di un feed di amici su Facebook, non importa se tutti vedono il tuo aggiornamento del muro contemporaneamente. Se okey, se una persona è in ritardo di alcuni battiti per alcuni secondi e raggiungono. Spesso non è fondamentale in molti progetti di sistemi che tutto sia mantenuto perfettamente coerente e che tutti abbiano una visione perfettamente coerente e la stessa del database. Quindi potremmo semplicemente tollerare un po 'di incoerenza che è in qualche modo temporanea.

Update, findAndModify, $addToSet(All'interno di un aggiornamento) e $push(all'interno di un aggiornamento) operazioni operano atomicamente in un singolo documento.

Controllare questo fuori, da Tokutek. Sviluppano un plugin per Mongo che promette non solo transazioni ma anche un aumento delle prestazioni.

Portalo al punto: se l'integrità transazionale è un must, allora non usare MongoDB ma usa solo componenti nel sistema che supportano le transazioni. È estremamente difficile creare qualcosa sopra il componente al fine di fornire funzionalità simili a ACID per componenti non ACID compatibili. A seconda dei singoli casi d'uso, può essere sensato separare le azioni in azioni transazionali e non transazionali in qualche modo ...

Ora qual è il problema con quello? MongoDB può eseguire aggiornamenti atomici su un solo documento. Nel flusso precedente potrebbe accadere che si insinui un qualche tipo di errore e che il messaggio venga archiviato nel database ma il saldo dell'utente non venga ridotto e / o la transazione non venga registrata.

Questo non è davvero un problema. L'errore che hai citato è un errore logico (bug) o IO (rete, errore del disco). Questo tipo di errore può lasciare sia i negozi senza transazione che quelli transazionali in uno stato non coerente. Ad esempio, se ha già inviato SMS ma durante la memorizzazione si è verificato un errore del messaggio, non è possibile ripristinare l'invio di SMS, il che significa che non verrà registrato, il saldo dell'utente non verrà ridotto, ecc.

Il vero problema qui è che l'utente può trarre vantaggio dalle condizioni di gara e inviare più messaggi di quanti ne consenta il suo saldo. Questo vale anche per RDBMS, a meno che non si esegua l'invio di SMS all'interno della transazione con il blocco del campo di saldo (che sarebbe un grande collo di bottiglia). Come possibile soluzione per MongoDB sarebbe findAndModifyinnanzitutto utilizzare per ridurre il saldo e verificarlo, se è negativo non consentire l'invio e il rimborso dell'importo (incremento atomico). Se positivo, continua a inviare e nel caso in cui non riesca a rimborsare l'importo. La raccolta della cronologia del saldo può anche essere mantenuta per aiutare a correggere / verificare il campo del saldo.

Il progetto è semplice, ma devi supportare le transazioni per il pagamento, il che rende il tutto difficile. Quindi, ad esempio, un sistema di portale complesso con centinaia di raccolte (forum, chat, annunci, ecc ...) è in qualche modo più semplice, perché se perdi un forum o una voce di chat, a nessuno importa davvero. Se, d'altra parte, perdi una transazione di pagamento che è un problema serio.

Quindi, se vuoi davvero un progetto pilota per MongoDB, scegline uno che sia semplice da questo punto di vista.

Le transazioni sono assenti in MongoDB per validi motivi. Questa è una di quelle cose che rendono MongoDB più veloce.

Nel tuo caso, se la transazione è un must, mongo non sembra adatto.

Può essere RDMBS + MongoDB, ma ciò aggiungerà complessità e renderà più difficile la gestione e il supporto dell'applicazione.

Questo è probabilmente il miglior blog che ho trovato sull'implementazione di funzionalità simili a transazioni per mongodb.!

Flag di sincronizzazione: ideale per copiare semplicemente i dati da un documento master

Coda dei lavori: scopo molto generale, risolve il 95% dei casi. La maggior parte dei sistemi deve comunque avere almeno una coda di lavoro in giro!

Commit a due fasi: questa tecnica garantisce che ogni entità abbia sempre tutte le informazioni necessarie per raggiungere uno stato coerente

Log riconciliazione: la tecnica più solida, ideale per i sistemi finanziari

Controllo delle versioni: fornisce isolamento e supporta strutture complesse

Leggi questo per maggiori informazioni: https://dzone.com/articles/how-implement-robust-and

È tardi, ma penso che questo aiuterà in futuro. Uso Redis per fare una coda per risolvere questo problema.

• Requisito: l'
  immagine seguente mostra 2 azioni che devono essere eseguite contemporaneamente ma la fase 2 e la fase 3 dell'azione 1 devono essere completate prima dell'inizio della fase 2 dell'azione 2 o opposta (una fase può essere una richiesta REST api, una richiesta del database o eseguire il codice javascript ... ).

• In che modo una coda ti aiuta a
  fare in modo che ogni codice di blocco tra lock()e release()in molte funzioni non funzionerà contemporaneamente, rendili isolati.

  function action1() {
    phase1();
    queue.lock("action_domain");
    phase2();
    phase3();
    queue.release("action_domain");
  }
  
  function action2() {
    phase1();
    queue.lock("action_domain");
    phase2();
    queue.release("action_domain");
  }

• Come costruire una coda
  Mi concentrerò solo su come evitare la parte conditon della gara quando costruisco una coda sul sito di backend. Se non conosci l'idea di base della coda, vieni qui .
  Il codice seguente mostra solo il concetto, è necessario implementarlo in modo corretto.

  function lock() {
    if(isRunning()) {
      addIsolateCodeToQueue(); //use callback, delegate, function pointer... depend on your language
    } else {
      setStateToRunning();
      pickOneAndExecute();
    }
  }
  
  function release() {
    setStateToRelease();
    pickOneAndExecute();
  }

Ma devi isRunning() setStateToRelease() setStateToRunning()isolare se stesso, altrimenti dovrai affrontare di nuovo le condizioni della razza. Per fare ciò ho scelto Redis per scopi ACID e scalabile.
Il documento Redis parla della sua transazione:

Tutti i comandi in una transazione sono serializzati ed eseguiti in sequenza. Non può mai accadere che una richiesta emessa da un altro cliente sia servita nel mezzo dell'esecuzione di una transazione Redis. Ciò garantisce che i comandi vengano eseguiti come un'unica operazione isolata.

P / s:
io uso Redis perché il mio servizio lo usa già, è possibile utilizzare qualsiasi altro supporto per l'isolamento per farlo.
Il action_domainnel mio codice è sopra per quando hai bisogno solo dell'azione 1 chiama dall'utente A blocca l'azione 2 dell'utente A, non bloccare l'altro utente. L'idea è mettere una chiave unica per il blocco di ogni utente.

Le transazioni sono ora disponibili in MongoDB 4.0. Esempio qui

// Runs the txnFunc and retries if TransientTransactionError encountered

function runTransactionWithRetry(txnFunc, session) {
    while (true) {
        try {
            txnFunc(session);  // performs transaction
            break;
        } catch (error) {
            // If transient error, retry the whole transaction
            if ( error.hasOwnProperty("errorLabels") && error.errorLabels.includes("TransientTransactionError")  ) {
                print("TransientTransactionError, retrying transaction ...");
                continue;
            } else {
                throw error;
            }
        }
    }
}

// Retries commit if UnknownTransactionCommitResult encountered

function commitWithRetry(session) {
    while (true) {
        try {
            session.commitTransaction(); // Uses write concern set at transaction start.
            print("Transaction committed.");
            break;
        } catch (error) {
            // Can retry commit
            if (error.hasOwnProperty("errorLabels") && error.errorLabels.includes("UnknownTransactionCommitResult") ) {
                print("UnknownTransactionCommitResult, retrying commit operation ...");
                continue;
            } else {
                print("Error during commit ...");
                throw error;
            }
       }
    }
}

// Updates two collections in a transactions

function updateEmployeeInfo(session) {
    employeesCollection = session.getDatabase("hr").employees;
    eventsCollection = session.getDatabase("reporting").events;

    session.startTransaction( { readConcern: { level: "snapshot" }, writeConcern: { w: "majority" } } );

    try{
        employeesCollection.updateOne( { employee: 3 }, { $set: { status: "Inactive" } } );
        eventsCollection.insertOne( { employee: 3, status: { new: "Inactive", old: "Active" } } );
    } catch (error) {
        print("Caught exception during transaction, aborting.");
        session.abortTransaction();
        throw error;
    }

    commitWithRetry(session);
}

// Start a session.
session = db.getMongo().startSession( { mode: "primary" } );

try{
   runTransactionWithRetry(updateEmployeeInfo, session);
} catch (error) {
   // Do something with error
} finally {
   session.endSession();
}