In che modo MongoDB esegue sia lo sharding che la replica allo stesso tempo?

Per il ridimensionamento/failover mongodb utilizza un "set di repliche" in cui sono presenti uno primario e uno o più server secondari. Primaria è utilizzata per le scritture. I secondari sono usati per le letture. Questo è praticamente uno schema di master slave utilizzato nella programmazione SQL. Se il primario scende un secondario nel gruppo di secondari prende il suo posto. Quindi il problema del ridimensionamento orizzontale e del failover è curato. Tuttavia, questa non è una soluzione che consente di condividere sembra. Un vero frammento contiene solo una parte dell'intero dato, quindi se il secondario in un set di repliche è shard, come può qualificare come primario quando non ha tutti i dati necessari per soddisfare le richieste?In che modo MongoDB esegue sia lo sharding che la replica allo stesso tempo?

Non dovremmo avere un set di repliche per ognuno dei frammenti?

Questa è ovviamente una domanda per principianti, quindi un collegamento che illustra visivamente o altrimenti come ciò è fatto potrebbe essere utile.

fonte

2013-02-06 alex sundukovskiy

Quel frammento avrà i dati necessari per soddisfare le richieste inviate ad esso, e sì si può avere una replica per frammento, ecco un tutorial del libro di cucina: http://cookbook.mongodb.org/operations/convert-replica- set-to-replicated-shard-cluster/ – Sammaye

L'ipotesi è corretta, ogni frammento contiene un set di repliche separato. Quando arriva una richiesta di scrittura, MongoS trova il frammento giusto per esso in base alla chiave shard e i dati vengono scritti nel Primario del set di repliche contenuto in quel frammento. Ciò si traduce in ridimensionamento della scrittura, in quanto una chiave (ben scelta) deve distribuire le scritture su tutti i frammenti.

fonte

2013-02-06 21:57:39

Grazie! Si può fare nel modo opposto? Ogni server in un cluster di set di repliche è sharded. Descrizione dettagliata: supponiamo di avere un set di repliche. Grande abbiamo avuto la possibilità di servire più letture, abbiamo ottenuto il failover. Ora il nostro problema è che la dimensione dei dati su ciascun server (che ho indicato come server) sta diventando piuttosto grande. Quindi dividiamo i dati su ciascun server. Non è il contrario di ciò che hai descritto? O è dal punto di vista dell'implementazione che è sempre la stessa "cosa"? –

@alexsundukovskiy Non sono sicuro di cosa intendi, ma non puoi copiare una replica in sé – Sammaye

@alexsundukovskiy Supponiamo che SHARD_KEY abbia valori possibili {A, B, C, D} e che tu abbia 2 frammenti. Ogni frammento ha una serie di repliche composta da 3 macchine. Ora, in teoria, i tuoi documenti dovrebbero essere distribuiti uniformemente sulla tua SHARD_KEY, ad es.il numero di documenti che arrivano con SHARD_KEY = A, SHARD_KEY = B ecc dovrebbe essere uguale. Diciamo che questa felice situazione continua per un po '. Quindi, una delle 2 cose inizia a succedere: (continua qui sotto) –

In genere si mappano i singoli frammenti per separare i set di repliche. Vedere http://docs.mongodb.org/manual/core/sharded-clusters/ per una panoramica della suddivisione in MongoDB.

fonte

2013-02-06 21:50:51 epc

Grazie, mi chiedo se mai succede il contrario. In altre parole, potremmo avere ogni nodo nel set di repliche sharded? E se no, cosa c'è di sbagliato nel farlo? –

Non sono sicuro di aver capito la tua domanda. È possibile suddividere le raccolte in un database e le esecuzioni di sharding in cima ai set di repliche. MongoDB non ha un concetto di sharding di un nodo. Potresti certamente scegliere di suddividere tutte le raccolte in tutti i tuoi database, tuttavia è probabilmente eccessivo a seconda del tuo carico di lavoro. – epc

Supponiamo di avere un set di repliche. Grande abbiamo avuto la possibilità di servire più letture, abbiamo ottenuto il failover. Ora il nostro problema è che la dimensione dei dati su ciascun server (che ho indicato come nodo) sta diventando piuttosto grande. Quindi dividiamo i dati su ciascun server. Non è il contrario di ciò che hai descritto? O è dal punto di vista dell'implementazione che è sempre la stessa "cosa"? –

Un frammento è la somma di un primario e secondari (set di repliche), quindi sì, si dovrebbe avere un set di repliche in ogni frammento.

La parte di tutti i dati è conservata nel primario ed è condivisa con i secondari per mantenere la coerenza. Se il primario si spegne, un secondario viene eletto come nuovo primario e ha gli stessi dati del suo predecessore per iniziare a servire immediatamente. Ciò significa che i dati non formattati sono ancora presenti e non vengono persi.

fonte

2013-02-06 21:59:09

Un frammento è un intervallo di dati della raccolta più grande, una replica può esistere senza un frammento e un frammento può esistere senza una replica – Sammaye

@Sammaye Non riesco a capire come un set di repliche possa esistere da solo in un ambiente più complesso. (potresti dire che non deve essere un frammento in un ambiente non-sharded?) Quando diciamo "shard", non intendiamo che il set di repliche fa parte di un ambito di dati più grande? Per quanto riguarda il fatto che il frammento possa esistere senza un set di repliche, sono d'accordo. Ma non è stato il caso a mettere in atto, così ho adattato la mia risposta al suo scenario che prevedeva repliche, non singole unità. –

Esattamente la definizione di shard non è sempre all'interno di un ambiente replicato, sembrava come se esistesse la "definizione" di un frammento in una replica. Non sono ancora sicuro di cosa intenda per "somma di una primaria e di una secondaria", poiché se ciò dovesse accadere, il primario (il frammento) non avrebbe dati duplicati. I secondari sono repliche del primario, il frammento, bene il tipo di, dipende dalla replica lì – Sammaye

In che modo MongoDB esegue sia lo sharding che la replica allo stesso tempo?

risposta

Problemi correlati