MongoDB non è magicamente più veloce. Se memorizzi gli stessi dati, organizzati sostanzialmente nello stesso modo, e accedi ad essi esattamente nello stesso modo, non dovresti davvero aspettarti che i tuoi risultati siano molto diversi. Dopotutto, MySQL e MongoDB sono entrambi GPL, quindi se Mongo avesse un codice IO magicamente migliore, il team MySQL potrebbe semplicemente incorporarlo nella propria base di codice.
Le persone vedono le prestazioni di MongoDB nel mondo reale in gran parte perché MongoDB ti consente di eseguire query in un modo diverso che è più sensibile al tuo carico di lavoro.
Ad esempio, si consideri un progetto che ha mantenuto molte informazioni su un'entità complicata in modo normalizzato. Questo potrebbe facilmente utilizzare dozzine di tabelle in MySQL (o qualsiasi db relazionale) per archiviare i dati in forma normale, con molti indici necessari per garantire l'integrità relazionale tra le tabelle.
Ora considera lo stesso design con un archivio di documenti. Se tutte le tabelle correlate sono subordinate alla tabella principale (e spesso lo sono), potresti essere in grado di modellare i dati in modo tale che l'intera entità sia archiviata in un unico documento. In MongoDB puoi archiviarlo come un singolo documento, in un'unica raccolta. È qui che MongoDB inizia a consentire prestazioni superiori.
In MongoDB, per recuperare l'intera entità, devi eseguire:
- Una ricerca nell'indice sulla raccolta (supponendo che l'entità venga recuperata da id)
- Recupera il contenuto di una pagina del database (il documento json binario effettivo)
Quindi una ricerca b-tree e una pagina binaria letta. Log(n) + 1 IO. Se gli indici possono risiedere interamente in memoria, allora 1 IO.
In MySQL con 20 tabelle, devi eseguire:
- Una ricerca nell'indice sulla tabella radice (sempre, supponendo che l'entità venga recuperata da id)
- Con un indice cluster, possiamo presumere che i valori per la riga principale siano nell'indice
- 20+ ricerche nell'intervallo (si spera su un indice) per il valore pk dell'entità
- Probabilmente non si tratta di indici raggruppati, quindi le stesse oltre 20 ricerche di dati una volta individuate le righe figlio appropriate.
Quindi il totale per mysql, anche supponendo che tutti gli indici siano in memoria (che è più difficile dato che ce ne sono 20 volte di più) è di circa 20 ricerche nell'intervallo.
Queste ricerche di intervalli sono probabilmente costituite da IO casuali:tabelle diverse risiederanno sicuramente in punti diversi del disco ed è possibile che righe diverse nello stesso intervallo nella stessa tabella per un'entità potrebbero non essere contigue (a seconda di come l'entità è stata aggiornato, ecc.).
Quindi, per questo esempio, il conteggio finale è di circa 20 volte più IO con MySQL per accesso logico, rispetto a MongoDB.
Ecco come MongoDB può aumentare le prestazioni in alcuni casi d'uso .
