Dove sta mongodb nel teorema della PAC?

Ovunque guardo, vedo che MongoDB è CP. Ma quando approfondisco vedo che alla fine è coerente. È CP quando usi safe = true? In tal caso, significa che quando scrivo con safe = true, tutte le repliche verranno aggiornate prima di ottenere il risultato?

MongoDB è fortemente coerente per impostazione predefinita: se scrivi e poi leggi, supponendo che la scrittura abbia avuto successo sarai sempre in grado di leggere il risultato della scrittura che hai appena letto. Questo perché MongoDB è un sistema a master singolo e tutte le letture vanno al primario per impostazione predefinita. Se si abilita facoltativamente la lettura dai secondari, MongoDB diventa eventualmente coerente dove è possibile leggere i risultati non aggiornati.

MongoDB ottiene anche l'alta disponibilità tramite failover automatico nei set di repliche: http://www.mongodb.org/display/DOCS/Replica+Sets

Sono d'accordo con il post di Luccas. Non puoi semplicemente dire che MongoDB è CP / AP / CA, perché in realtà è un compromesso tra C, A e P, a seconda della configurazione del database / driver e del tipo di disastro : ecco un riepilogo visivo e sotto un spiegazione più dettagliata.

    Scenario                   | Main Focus | Description
    ---------------------------|------------|------------------------------------
    No partition               |     CA     | The system is available 
                               |            | and provides strong consistency
    ---------------------------|------------|------------------------------------
    partition,                 |     AP     | Not synchronized writes 
    majority connected         |            | from the old primary are ignored                
    ---------------------------|------------|------------------------------------
    partition,                 |     CP     | only read access is provided
    majority not connected     |            | to avoid separated and inconsistent systems

Consistenza:

MongoDB è fortemente coerente quando si utilizza una singola connessione o il livello di preoccupazione di scrittura / lettura corretto ( che ti costerà la velocità di esecuzione ). Non appena non soddisfi queste condizioni (specialmente quando stai leggendo da una replica secondaria) MongoDB diventa Eventually Consistent.

Disponibilità:

MongoDB ottiene la disponibilità elevata tramite i set di replica . Non appena la primaria si interrompe o non è più disponibile, le secondarie determineranno che una nuova primaria sarà nuovamente disponibile. C'è uno svantaggio in questo: ogni scrittura che è stata eseguita dal vecchio primario, ma non sincronizzata con le secondarie verrà annullata e salvata in un file di rollback, non appena si ricollegherà al set (la vecchia primaria è una secondaria adesso). Quindi in questo caso viene sacrificata una certa coerenza per motivi di disponibilità.

Tolleranza sulla partizione:

Attraverso l'uso di detti set di repliche, MongoDB raggiunge anche la tolleranza di partizione: fintanto che più della metà dei server di un set di repliche è collegata tra loro, è possibile scegliere un nuovo primario . Perché? Per garantire che due reti separate non possano entrambe scegliere una nuova primaria. Quando non sono collegati tra loro un numero sufficiente di secondari, è comunque possibile leggere da essi (ma la coerenza non è garantita), ma non scrivere. Il set è praticamente introvabile per motivi di coerenza.

Quando è apparso un nuovo brillante articolo e anche alcuni fantastici esperimenti di Kyle in questo campo, dovresti fare attenzione quando etichetti MongoDB e altri database come C o A.

Ovviamente CAP aiuta a rintracciare senza troppe parole ciò che il database prevale su di esso, ma le persone spesso dimenticano che C in CAP significa coerenza atomica (linearizzabilità), per esempio. E questo mi ha causato molto dolore da capire quando ho cercato di classificare. Quindi, oltre a MongoDB da una forte consistenza, ciò non significa che sia C. In questo modo, se si fanno queste classificazioni, consiglio di approfondire anche come funziona effettivamente per non lasciare dubbi.

Sì, è CP quando si utilizza safe=true. Questo significa semplicemente che i dati sono arrivati ​​al disco master. Se vuoi assicurarti che sia arrivato anche su qualche replica, guarda nel parametro 'w = N' dove N è il numero di repliche su cui devono essere salvati i dati.

vedere questo e questo per ulteriori informazioni.

Non sono sicuro di P per Mongo. Immagina la situazione:

• La tua replica viene divisa in due partizioni.
• Le scritture continuano ad entrambe le parti quando sono stati eletti nuovi maestri
• La partizione è stata risolta: tutti i server sono ora nuovamente connessi
• Quello che succede è che viene eletto il nuovo master, quello con l'oplog più alto, ma i dati dell'altro master vengono ripristinati allo stato comune prima della partizione e vengono scaricati in un file per il ripristino manuale
• tutte le secondarie raggiungono il nuovo master

Il problema qui è che la dimensione del file di dump è limitata e se hai una partizione per molto tempo puoi perdere i tuoi dati per sempre.

Puoi dire che è improbabile che accada, sì, a meno che non sia nel cloud dove è più comune di quanto si possa pensare.

Questo esempio è il motivo per cui starei molto attento prima di assegnare qualsiasi lettera a qualsiasi database. Ci sono così tanti scenari e implementazioni non perfette.

Se qualcuno sa se questo scenario è stato affrontato nelle versioni successive di Mongo, per favore commenta! (È da tempo che non seguo tutto ciò che accade ..)

Mongodb non consente mai la scrittura su secondario. Consente letture opzionali dal secondario ma non scritture. Quindi, se la tua primaria non funziona, non puoi scrivere finché una secondaria non diventa di nuovo primaria. È così che sacrifichi l'alta disponibilità nel teorema della CAP. Mantenendo le tue letture solo dalla primaria puoi avere una forte coerenza.

MongoDB seleziona la coerenza sulla disponibilità ogni volta che è presente una partizione. Ciò che significa è che quando c'è una partizione (P) sceglie Consistenza (C) su Disponibilità (A).

Per capire questo, capiamo come MongoDB fa funzionare il set di repliche. Un set di repliche ha un singolo nodo primario. L'unico modo "sicuro" per eseguire il commit dei dati è scrivere su quel nodo e quindi attendere che i dati si impegnino nella maggior parte dei nodi dell'insieme. (vedrai quel flag per w = maggioranza quando invii le scritture)

La partizione può verificarsi in due scenari come segue:

• Quando il nodo primario si interrompe: il sistema non è disponibile finché non viene selezionato un nuovo nodo primario.
• Quando il nodo primario perde la connessione da troppi nodi secondari: il sistema diventa non disponibile. Altre secondarie cercheranno di eleggere una nuova primaria e quella attuale si dimetterà.

Fondamentalmente, ogni volta che si verifica una partizione e MongoDB deve decidere cosa fare, sceglierà Consistency over Availability. Smetterà di accettare le scritture sul sistema finché non riterrà di poterle completare in sicurezza.

Mongodb fornisce coerenza e tolleranza di partizione .

Nel contesto dei database distribuiti (NoSQL), ciò significa che ci sarà sempre un compromesso tra coerenza e disponibilità. Questo perché i sistemi distribuiti sono sempre necessariamente tolleranti alle partizioni (cioè semplicemente non sarebbe un database distribuito se non fosse tollerante alle partizioni).

Coerenza : il sistema alla fine diventerà coerente. I dati si propagheranno ovunque prima o poi, ma il sistema continuerà a ricevere input e non verificherà la coerenza di ogni transazione prima di passare a quella successiva.

Disponibilità : per impostazione predefinita, Mongo DB Client (driver MongoDB) invia tutte le richieste di lettura / scrittura al nodo leader / primario. Rende il sistema coerente ma non disponibile a causa di: - Se un leader si disconnette dal cluster, sono necessari alcuni secondi per eleggere un nuovo leader. Quindi, rendendolo non disponibile per scritture e letture in quella durata.