MongoDB är inte magiskt snabbare. Om du lagrar samma data, organiserad på i princip samma sätt, och får åtkomst till den på exakt samma sätt, så ska du verkligen inte förvänta dig att dina resultat ska vara väldigt annorlunda. När allt kommer omkring är MySQL och MongoDB båda GPL, så om Mongo hade någon magiskt bättre IO-kod i sig, så skulle MySQL-teamet bara kunna införliva den i sin kodbas.
Människor ser verkliga MongoDB-prestanda till stor del för att MongoDB låter dig fråga på ett annat sätt som är mer förnuftigt för din arbetsbelastning.
Tänk till exempel på en design som bevarade mycket information om en komplicerad enhet på ett normaliserat sätt. Detta skulle lätt kunna använda dussintals tabeller i MySQL (eller någon relationsdb) för att lagra data i normal form, med många index som behövs för att säkerställa relationsintegritet mellan tabeller.
Tänk nu på samma design med en dokumentaffär. Om alla dessa relaterade tabeller är underordnade huvudtabellen (och det är de ofta), kan du kanske modellera data så att hela enheten lagras i ett enda dokument. I MongoDB kan du lagra detta som ett enda dokument, i en enda samling. Det är här MongoDB börjar möjliggöra överlägsen prestanda.
I MongoDB, för att hämta hela entiteten, måste du utföra:
- En indexsökning på samlingen (förutsatt att entiteten hämtas av id)
- Hämta innehållet på en databassida (det faktiska binära json-dokumentet)
Så en b-träduppslagning och en binär sida läst. Log(n) + 1 IO. Om indexen kan ligga helt i minnet, då 1 IO.
I MySQL med 20 tabeller måste du utföra:
- En indexuppslagning i rottabellen (igen, förutsatt att entiteten hämtas av id)
- Med ett klustrat index kan vi anta att värdena för rotraden finns i indexet
- 20+ intervallsökningar (förhoppningsvis på ett index) för enhetens pk-värde
- Dessa är förmodligen inte klustrade index, så samma 20+ datauppslagningar när vi väl tar reda på vilka lämpliga underordnade rader är.
Så summan för mysql, även om man antar att alla index finns i minnet (vilket är svårare eftersom det finns 20 gånger fler av dem) är cirka 20 intervalluppslagningar.
Dessa intervalluppslagningar består sannolikt av slumpmässiga IO - olika tabeller kommer definitivt att finnas på olika platser på disken, och det är möjligt att olika rader i samma intervall i samma tabell för en enhet kanske inte är sammanhängande (beroende på hur entiteten har varit uppdaterad, etc).
Så för det här exemplet är slutsumman ungefär 20 gånger mer IO med MySQL per logisk åtkomst, jämfört med MongoDB.
Så här kan MongoDB öka prestandan i vissa användningsfall .