Der Inhalt dieses Artikels befasst sich mit der vergleichenden Analyse zwischen Mongodb und MySQL. Ich hoffe, dass er für Freunde hilfreich ist.
In den in der Datenbank gespeicherten Daten gibt es einen speziellen Schlüsselwert namens Primärschlüssel , der zur eindeutigen Identifizierung eines Datensatzes in der Tabelle verwendet wird. Mit anderen Worten: Eine Tabelle kann nicht mehrere Primärschlüssel haben und der Primärschlüssel darf nicht null sein. Unabhängig davon, ob es sich um MongoDB oder MySQL handelt, hat die Definition eines Primärschlüssels .
Für MongoDB heißt der Primärschlüssel „_id“. Wenn der Benutzer ihm beim Generieren keinen Primärschlüssel zuweist, generiert MongoDB automatisch einen zufällig zugewiesenen Wert.
In MySQL wird die Bezeichnung des Primärschlüssels durch die Angabe von PRIMARY KEY definiert, wenn MySQL Daten einfügt. Wenn der Primärschlüssel nicht angegeben ist, ersetzt ein anderes Tool – der Index – die Funktion des Primärschlüssels. Der Index kann leer sein oder Duplikate enthalten. Es gibt einen anderen Indextyp, der keine Duplikate zulässt, einen sogenannten eindeutigen Index. Wenn weder ein Primärschlüssel noch ein Index angegeben ist, erstellt MySQL automatisch einen für die Daten.
Speichergeschwindigkeitsvergleich
1. Durchschnittliche Datenbankeinfügungsrate: _id-Einfügung> MySQL gibt keine Primärschlüsseleinfügung an> Gibt _id zum Einfügen an.
2. MongoDB weist beim Einfügen mit und ohne Angabe von _id einen großen Geschwindigkeitsunterschied auf, bei MySQL ist der Unterschied jedoch viel geringer.
Analyse:
1. Bei der Angabe von _id oder Primärschlüssel müssen die beiden Datenbanken beim Einfügen den Indexwert verarbeiten und feststellen, ob in der Datei derselbe Wert vorhanden ist Datenbankschlüsselwert, der die Einfügungsrate verlangsamt.
2. In MongoDB ist das Angeben des Indexeinfügens viel langsamer als das Nichtangeben. Dies liegt daran, dass der _id-Wert jedes Datenelements in MongoDB eindeutig ist. Wenn Daten ohne Angabe von _id eingefügt werden, wird deren _id automatisch vom System berechnet und generiert. MongoDB verwendet Computereigenschaften, Zeit, Prozess-ID und Zufallszahlen, um sicherzustellen, dass die generierte _id eindeutig ist. Beim Einfügen durch Angabe von _id muss MongoDB bei jedem Einfügen eines Datenelements prüfen, ob diese _id verfügbar ist. Wenn zu viele Datenelemente in der Datenbank vorhanden sind, verlangsamt der Abfrageaufwand dieses Schritts die Einfügegeschwindigkeit des gesamten Datenbank.
3. MongoDB nutzt den Systemspeicher vollständig als Cache, was eine sehr hervorragende Funktion ist. Unsere Testmaschine verfügt über 64 GB Speicher. Beim Einfügen versucht MongoDB sein Bestes, die Daten auf der Festplatte beizubehalten, nachdem der Speicher fast voll ist. Dies ist auch der Grund, warum MongoDB beim Einfügen ohne Angabe von _id weitaus effizienter ist. Wenn jedoch beim Einfügen durch Angabe von _id die Datenmenge zu groß ist, um in den Speicher zu passen, muss MongoDB die Informationen von der Festplatte in den Speicher lesen, um auf Duplikate zu prüfen, was die Einfügungseffizienz verlangsamt.
4. MySQL ist in der Tat eine sehr stabile Datenbank, unabhängig davon, ob der Primärschlüssel angegeben oder ohne Angabe des Primärschlüssels eingefügt wird.
Einfügungsstabilitätsanalyse
Einfügungsstabilität bezieht sich auf die Einfügungsrate, wenn eine bestimmte Datenmenge mit zunehmender Datenmenge eingefügt wird.
In diesem Test haben wir die Skala dieses Indikators auf 100.000 eingestellt, d. h. die angezeigten Daten geben an, wie viele Daten pro Sekunde in diesem Zeitraum eingefügt werden können, wenn 100.000 Daten eingefügt werden.
Zuerst präsentieren Sie vier Bilder:
1. MongoDB gibt _id-Einfügung an:
2. MongoDB gibt keine _id-Einfügung an:
3. MySQL gibt PRIMARY KEY zum Einfügen an:
4. MySQL gibt keinen PRIMARY KEY zum Einfügen an:
Zusammenfassung:
1. Die Gesamteinfügungsgeschwindigkeit ähnelt immer noch den Statistiken der vorherigen Folge: MongoDB gibt keine _id zum Einfügen an> MySQL gibt keinen Primärschlüssel zum Einfügen an> MySQL gibt _id zum Einfügen an.
2. Wie aus der Abbildung hervorgeht, schwanken die pro Sekunde eingefügten Daten hin und wieder, wenn MySQL und MongoDB unterschiedliche Datengrößenordnungen haben Das Diagramm zeigt regelmäßig Störungen an. Wenn das Einfügen von Daten nicht angegeben ist, ist die Einfügungsrate in den meisten Fällen relativ durchschnittlich. Mit zunehmender Datenmenge in der Datenbank sinkt die Einfügungseffizienz jedoch vorübergehend und stabilisiert sich dann wieder.
3. Insgesamt sind die Ratenschwankungen bei MongoDB gravierender als bei MySQL und die Varianz ändert sich erheblich.
4. Wenn MongoDB durch Angabe von _id einfügt, sinkt die Einfügungseffizienz erheblich, wenn mehr Daten eingefügt werden. Bei den anderen drei Einfügungstests ist die Einfügungsrate die meiste Zeit vom Anfang bis zum Ende auf einen Standard festgelegt.
Analyse:
1. Das Glitch-Phänomen liegt daran, dass MongoDB die Daten im Speicher auf die Festplatte und MySQL schreiben muss, wenn zu viele Daten eingefügt werden Untertabelle muss neu geschrieben werden. Diese Vorgänge werden automatisch ausgeführt, wenn die Daten in der Datenbank ein bestimmtes Niveau erreichen, sodass hin und wieder ein offensichtlicher Fehler auftritt.
2. MongoDB ist immer noch eine neue Sache und seine Stabilität ist nicht so gut wie MySQL, das seit vielen Jahren verwendet wird.
3. Wenn MongoDB die angegebene _id einfügt, sinkt die Leistung erheblich.
4. Wenn die Größe der gelesenen Daten nicht groß ist, ist die Abfragegeschwindigkeit von MongoDB wirklich beispiellos und lässt MySQL weit hinter sich.
5. Da die Menge der abgefragten Daten allmählich zunimmt, nimmt die Abfragegeschwindigkeit von MySQL stetig ab, während die Abfragegeschwindigkeit von MongoDB etwas schwankt.
Analyse:
1. Wenn MySQL nicht abfrageoptimiert wurde, sollte seine Abfragegeschwindigkeit nicht mit MongoDB verglichen werden. MongoDB kann die Speicherressourcen des Systems voll ausnutzen. Je größer der Speicher, desto schneller ist die Abfragegeschwindigkeit von MongoDB .
2. Die Abfragedaten in diesem Experiment werden ebenfalls zufällig generiert, sodass die Wahrscheinlichkeit, dass alle abzufragenden Daten im Speichercache von MongoDB gespeichert werden, sehr gering ist. Bei der Abfrage muss MongoDB mehrmals mit den Daten im Speicher und auf der Festplatte interagieren, um sie zu finden. Daher hängt die Abfragerate von der Anzahl der Interaktionen ab. Es besteht die Möglichkeit, dass, obwohl die abzufragende Datenmenge größer ist, diese zufällig generierten Daten von MongoDB weniger oft von der Festplatte abgerufen werden. Daher ist die durchschnittliche Abfragegeschwindigkeit schneller. Unter diesem Gesichtspunkt liegen auch die Schwankungen der Abfragegeschwindigkeit von MongoDB in einem angemessenen Bereich.
3. An der Stabilität von MySQL besteht kein Zweifel.
Fazit
1. Im Vergleich zu MySQL eignet sich die MongoDB-Datenbank besser für Aufgabenmodelle mit umfangreichen Lesevorgängen. MongoDB kann die Speicherressourcen der Maschine vollständig nutzen. Wenn die Maschine über reichlich Speicherressourcen verfügt, ist die Abfrageeffizienz von MongoDB viel schneller.
2. Beim Einfügen von Daten mit „_id“ ist die Einfügungseffizienz von MongoDB tatsächlich nicht hoch. Wenn Sie die MongoDB-Leistung voll ausnutzen möchten, empfiehlt es sich, ohne „_id“ einzufügen und dann die relevanten Felder für die Abfrage zu indizieren.
3. MongoDB eignet sich für Nachfragemodelle, bei denen das spezifische Datenformat der Datenbank unklar ist oder sich das Datenbankdatenformat häufig ändert, und ist sehr entwicklerfreundlich.
4. MongoDB verfügt offiziell über ein verteiltes Dateisystem, das problemlos auf einem Servercluster bereitgestellt werden kann. In MongoDB gibt es ein Shard-Konzept, das für das Server-Sharding praktisch ist. Mit jedem zusätzlichen Shard verdoppelt sich die Einfügungsleistung von MongoDB nahezu und die Festplattenkapazität kann problemlos erweitert werden.
5. MongoDB bietet außerdem Unterstützung für das Map-Reduce-Computing-Framework, das auch für Datenstatistiken sehr praktisch ist.
Mängel von MongoDB
1. Schwache Unterstützung für Transaktionsbeziehungen. Dies ist auch ein gemeinsamer Fehler aller NoSQL-Datenbanken. Allerdings ist NoSQL nicht für Transaktionsbeziehungen konzipiert und wird immer noch für bestimmte Anwendungen nachgefragt.
2. Die Stabilität ist etwas mangelhaft, wie aus dem obigen Test hervorgeht.
3. Einerseits ist MongoDB komfortabel für Entwickler, andererseits stellt es erhebliche Anforderungen an das Betriebs- und Wartungspersonal. In der Branche gibt es keine ausgereifte Erfahrung mit MongoDB-Betrieb und -Wartung, und das Speicherformat der Daten in MongoDB ist ebenfalls sehr zufällig. Probleme wie diese stellen eine Prüfung für das Betriebs- und Wartungspersonal dar.
Das obige ist der detaillierte Inhalt vonVergleichende Analyse zwischen Mongodb und MySQL. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
