MongoDB er ikke magisk hurtigere. Hvis du gemmer de samme data, organiseret på stort set samme måde, og får adgang til det nøjagtigt på samme måde, så skal du virkelig ikke forvente, at dine resultater er vildt anderledes. Når alt kommer til alt, er MySQL og MongoDB begge GPL, så hvis Mongo havde noget magisk bedre IO-kode i sig, så kunne MySQL-teamet bare inkorporere det i deres kodebase.
Folk ser MongoDB-ydeevne i den virkelige verden, hovedsagelig fordi MongoDB giver dig mulighed for at forespørge på en anden måde, der er mere fornuftig for din arbejdsbyrde.
Overvej f.eks. et design, der bevarer en masse information om en kompliceret enhed på en normaliseret måde. Dette kunne nemt bruge snesevis af tabeller i MySQL (eller enhver relationel db) til at gemme dataene i normal form, med mange indekser nødvendige for at sikre relationel integritet mellem tabeller.
Overvej nu det samme design med en dokumentbutik. Hvis alle disse relaterede tabeller er underordnet hovedtabellen (og det er de ofte), så kan du muligvis modellere dataene sådan, at hele entiteten er gemt i et enkelt dokument. I MongoDB kan du gemme dette som et enkelt dokument, i en enkelt samling. Det er her, MongoDB begynder at muliggøre overlegen ydeevne.
I MongoDB skal du udføre:
for at hente hele entiteten- Ét indeksopslag på samlingen (forudsat at enheden er hentet af id)
- Hent indholdet af én databaseside (det faktiske binære json-dokument)
Så et b-træ opslag, og en binær side læst. Log(n) + 1 IO'er. Hvis indekserne kan ligge helt i hukommelsen, så 1 IO.
I MySQL med 20 tabeller skal du udføre:
- Ét indeksopslag på rodtabellen (igen, forudsat at entiteten er hentet af id)
- Med et klynget indeks kan vi antage, at værdierne for rodrækken er i indekset
- 20+ områdeopslag (forhåbentlig på et indeks) for enhedens pk-værdi
- Disse er sandsynligvis ikke klyngede indekser, så de samme 20+ dataopslag, når vi finder ud af, hvad de passende underordnede rækker er.
Så summen for mysql, selv hvis det antages, at alle indekser er i hukommelsen (hvilket er sværere, da der er 20 gange flere af dem), er omkring 20 rækkeopslag.
Disse områdeopslag består sandsynligvis af tilfældige IO — forskellige tabeller vil helt sikkert ligge på forskellige steder på disken, og det er muligt, at forskellige rækker i det samme område i den samme tabel for en enhed muligvis ikke er sammenhængende (afhængigt af hvordan entiteten har været opdateret osv.).
Så for dette eksempel er den endelige opgørelse omkring 20 gange mere IO med MySQL pr. logisk adgang sammenlignet med MongoDB.
Sådan kan MongoDB øge ydeevnen i nogle tilfælde .