Lo sharding è efficace per le piccole collezioni?

11

Sembra che lo sharding del database sia fantastico se ho raccolte enormi. Cosa succede se ho molte collezioni di dimensioni adeguate? Diciamo che per 1 raccolta di 100.000.000 di documenti (commenti non molto grandi) lo sharding è efficace. È efficace anche per 10.000 raccolte con 10.000 documenti ciascuna?

(Penso che questa domanda sia ancora valida per i database orientati alle tabelle se si sostituiscono raccolte con tabelle e documenti con righe. Se possibile, vorrei conoscere la risposta teorica e la risposta nello specifico scenario MongoDB, se diverso dal teorico risposta.)

mongodb

— João Pinto Jerónimo
fonte

5

È efficace anche per 10.000 raccolte con 10.000 documenti ciascuna?

La maggior parte delle persone ha il problema della "raccolta di grandi dimensioni singola" e quindi lo sharding è chiaramente utile per ridurre il mal di testa nel bilanciare questi dati.

Tuttavia, quando hai 10.000 raccolte piccole, il tuo mal di testa probabilmente non sta "bilanciando i dati". Con così tante piccole raccolte il tuo problema è probabilmente relativo al monitoraggio di queste raccolte. A seconda delle dimensioni del documento, è possibile che non si verifichi nemmeno il limite inferiore affinché si verifichi effettivamente lo sharding.

Per raccolte molto piccole, è possibile utilizzare il comando movePrimary poco noto per gestire la posizione dei dati.

Ovviamente, l'altro modo di vedere questo è perché hai collezioni 10k? Una collezione non ha bisogno di oggetti omogenei e con raccolte da 10k la maggior parte deve essere generata. È possibile memorizzare diversi "tipi" di dati nella stessa raccolta, ridurre il numero di raccolte e quindi includere il tipo come parte della chiave di shard.

— Gates VP
fonte

Grazie, stavo esattamente cercando di sapere se il meglio che potevo fare è liberarmi di queste tonnellate di collezioni e crearne una grande. Avevo tonnellate di raccolte prima perché avevo sentito una convinzione comune: "Le raccolte enormi sono dannose per te perché gli indici non si adattano alla RAM e sarà molto lentamente interrogarli e aggiornarli". Ma immagino che lo sharding sia stato creato per risolvere quel problema ... Grazie !!

— João Pinto Jerónimo,

Onestamente, trovo che spesso puoi "imbrogliare" anche sugli indici. Se si dispone di due collezioni fooe barcon la stessa struttura di dati, è possibile unire nella bazraccolta e ignorare il _ids(in codice): { _id: "foo123" }, { _id: "bar123" }. Hai un indice più grande, ma hai solo un indice che include il tipo. Non è un requisito, solo "spunti di riflessione".

— Gates VP,

4

Lo sharding MongoDB funziona suddividendo una raccolta in "blocchi" più piccoli e distribuendoli uniformemente su un numero di macchine. La dimensione predefinita del blocco, che è generalmente la più efficiente, è di 200 MB. Quindi, a meno che una raccolta non sia molto più grande di 200 MB, non si dividerà in grossi pezzi, e quindi non sarà ammissibile allo sharding, quindi non ci saranno benefici.

In generale, la condivisione dei dati su più macchine è un modo molto efficace per ridimensionare letture, scritture e query. Ottieni i vantaggi di più CPU, hard disk e memoria, lavorando in parallelo per leggere, scrivere ed elaborare i dati. Il ridimensionamento della memoria è particolarmente importante per MongoDB, dove le alte prestazioni sono molto sensibili all'adattamento dei dati in memoria.

— Chris Fulstow
fonte

La dimensione del blocco predefinito di FYI è 64 MB a partire da 1.8.

— Gates VP,