MongoDB is niet magisch sneller. Als je dezelfde gegevens opslaat, in principe op dezelfde manier georganiseerd, en er op precies dezelfde manier toegang toe hebt, dan zou je echt niet moeten verwachten dat je resultaten enorm verschillen. MySQL en MongoDB zijn tenslotte beide GPL, dus als Mongo een magisch betere IO-code had, zou het MySQL-team het gewoon in hun codebase kunnen opnemen.
Mensen zien MongoDB-prestaties in de echte wereld grotendeels omdat MongoDB u in staat stelt om op een andere manier te zoeken die beter past bij uw werklast.
Beschouw bijvoorbeeld een ontwerp dat veel informatie over een gecompliceerde entiteit op een genormaliseerde manier bevatte. Dit kan gemakkelijk tientallen tabellen in MySQL (of een relationele db) gebruiken om de gegevens in normale vorm op te slaan, met veel indexen die nodig zijn om de relationele integriteit tussen tabellen te garanderen.
Overweeg nu hetzelfde ontwerp met een documentopslag. Als al die gerelateerde tabellen ondergeschikt zijn aan de hoofdtabel (en dat zijn ze vaak), dan kunt u de gegevens misschien zo modelleren dat de hele entiteit in één document wordt opgeslagen. In MongoDB kun je dit als één document opslaan, in één verzameling. Dit is waar MongoDB begint met het mogelijk maken van superieure prestaties.
In MongoDB, om de hele entiteit op te halen, moet je het volgende doen:
- Eén indexzoekopdracht voor de collectie (ervan uitgaande dat de entiteit wordt opgehaald door id)
- De inhoud van één databasepagina ophalen (het daadwerkelijke binaire json-document)
Dus een b-tree-lookup en een binaire pagina lezen. Log(n) + 1 IO's. Als de indexen volledig in het geheugen kunnen staan, dan 1 IO.
In MySQL met 20 tabellen moet je het volgende doen:
- Eén indexzoekopdracht in de hoofdtabel (opnieuw, ervan uitgaande dat de entiteit wordt opgehaald door id)
- Bij een geclusterde index kunnen we aannemen dat de waarden voor de root-rij in de index staan
- 20+ bereikzoekopdrachten (hopelijk op een index) voor de pk-waarde van de entiteit
- Dit zijn waarschijnlijk geen geclusterde indexen, dus dezelfde 20+ gegevenszoekacties zodra we weten wat de juiste onderliggende rijen zijn.
Dus het totaal voor mysql, zelfs als we aannemen dat alle indexen in het geheugen staan (wat moeilijker is omdat er 20 keer meer zijn), is ongeveer 20 bereikzoekopdrachten.
Deze zoekacties voor het bereik bestaan waarschijnlijk uit willekeurige IO - verschillende tabellen zullen zich zeker op verschillende plaatsen op de schijf bevinden, en het is mogelijk dat verschillende rijen in hetzelfde bereik in dezelfde tabel voor een entiteit niet aaneengesloten zijn (afhankelijk van hoe de entiteit is bijgewerkt, enz.).
Dus voor dit voorbeeld is de uiteindelijke telling ongeveer 20 keer meer IO met MySQL per logische toegang, vergeleken met MongoDB.
Dit is hoe MongoDB de prestaties kan verbeteren in sommige gevallen .