MongoDB ist nicht magisch schneller. Wenn Sie die gleichen Daten speichern, im Grunde auf die gleiche Weise organisiert sind und auf die gleiche Weise darauf zugreifen, sollten Sie wirklich nicht erwarten, dass Ihre Ergebnisse völlig unterschiedlich sind. Schließlich sind MySQL und MongoDB beide GPL. Wenn also Mongo einen magisch besseren IO-Code enthalten hätte, könnte das MySQL-Team ihn einfach in seine Codebasis integrieren.
Die Leute sehen die MongoDB-Leistung in der realen Welt vor allem deshalb, weil MongoDB es Ihnen ermöglicht, Abfragen auf eine andere Weise durchzuführen, die für Ihre Arbeitslast sinnvoller ist.
Stellen Sie sich beispielsweise ein Design vor, das viele Informationen über eine komplizierte Entität auf normalisierte Weise gespeichert hat. Dies könnte problemlos Dutzende von Tabellen in MySQL (oder einer relationalen Datenbank) verwenden, um die Daten in normaler Form zu speichern, wobei viele Indizes erforderlich sind, um die relationale Integrität zwischen Tabellen sicherzustellen.
Betrachten Sie nun das gleiche Design mit einem Dokumentenspeicher. Wenn alle diese verknüpften Tabellen der Haupttabelle untergeordnet sind (was häufig der Fall ist), können Sie die Daten möglicherweise so modellieren, dass die gesamte Entität in einem einzigen Dokument gespeichert wird. In MongoDB können Sie dies als einzelnes Dokument in einer einzelnen Sammlung speichern. Hier setzt MongoDB an, um eine überlegene Leistung zu ermöglichen.
In MongoDB müssen Sie Folgendes ausführen, um die gesamte Entität abzurufen:
- Eine Indexsuche für die Sammlung (vorausgesetzt, die Entität wird über die ID abgerufen)
- Ruft den Inhalt einer Datenbankseite ab (das eigentliche binäre JSON-Dokument)
Also eine B-Tree-Suche und eine Binärseite gelesen. Log(n) + 1 IOs. Wenn sich die Indizes vollständig im Speicher befinden können, dann 1 IO.
In MySQL mit 20 Tabellen müssen Sie Folgendes ausführen:
- Eine Indexsuche in der Stammtabelle (wieder unter der Annahme, dass die Entität anhand der ID abgerufen wird)
- Bei einem geclusterten Index können wir davon ausgehen, dass sich die Werte für die Stammzeile im Index befinden
- Über 20 Bereichssuchen (hoffentlich auf einem Index) für den pk-Wert der Entität
- Dies sind wahrscheinlich keine geclusterten Indizes, also die gleichen mehr als 20 Datensuchen, sobald wir herausgefunden haben, was die entsprechenden untergeordneten Zeilen sind.
Also beträgt die Gesamtzahl für mysql, selbst unter der Annahme, dass sich alle Indizes im Speicher befinden (was schwieriger ist, da es 20-mal mehr davon gibt), ungefähr 20 Bereichssuchen.
Diese Bereichssuchen bestehen wahrscheinlich aus zufälligen E/A – verschiedene Tabellen befinden sich definitiv an verschiedenen Stellen auf der Festplatte, und es ist möglich, dass verschiedene Zeilen im selben Bereich in derselben Tabelle für eine Entität möglicherweise nicht zusammenhängend sind (je nachdem, wie die Entität war). aktualisiert usw.).
In diesem Beispiel beträgt die endgültige Zählung also ungefähr 20 Mal mehr IO mit MySQL pro logischem Zugriff im Vergleich zu MongoDB.
So kann MongoDB die Leistung in einigen Anwendungsfällen steigern .
