Analyse comparative entre Mongodb et MySQL

Le contenu de cet article concerne l'analyse comparative entre Mongodb et MySQL. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

Dans les données stockées dans la base de données, il existe une valeur de clé spéciale appelée clé primaire, qui est utilisée pour identifier de manière unique un enregistrement dans la table. En d’autres termes, une table ne peut pas avoir plusieurs clés primaires et la clé primaire ne peut pas être nulle. Qu'il s'agisse de MongoDB ou de MySQL, a la définition de clé primaire .
Pour MongoDB, la clé primaire est appelée "_id". Lors de la génération de données, si l'utilisateur ne lui attribue pas activement de clé primaire, MongoDB générera automatiquement une valeur attribuée aléatoirement.

Dans MySQL, la désignation de la clé primaire est définie en spécifiant PRIMARY KEY lorsque MySQL insère des données. Lorsque la clé primaire n'est pas spécifiée, un autre outil - l'index, équivaut à remplacer la fonction de la clé primaire. L'index peut être vide ou comporter des doublons. Il existe un autre type d'index qui n'autorise pas les doublons, appelé index unique. Si ni une clé primaire ni un index ne sont spécifiés, MySQL en créera automatiquement une pour les données.

Comparaison de la vitesse de stockage

1. Taux d'insertion moyen de la base de données : MongoDB ne spécifie pas l'insertion de _id> MySQL ne spécifie pas l'insertion de clé primaire> spécifie _id pour l'insertion.

2. MongoDB a une grande différence de vitesse lors de l'insertion avec et sans spécifier _id, mais la différence dans MySQL est beaucoup plus petite.

Analyse :

1 Lors de la spécification de _id ou de la clé primaire, les deux bases de données doivent traiter la valeur d'index lors de l'insertion et déterminer si la même valeur existe dans la base de données. valeur clé, ce qui ralentira le taux d’insertion.

2. Dans MongoDB, spécifier l'insertion d'un index est beaucoup plus lent que ne pas la spécifier. En effet, la valeur _id de chaque élément de données dans MongoDB est unique. Lorsque des données sont insérées sans spécifier _id, son _id est automatiquement calculé et généré par le système. MongoDB utilise les caractéristiques de l'ordinateur, l'heure, l'ID de processus et des nombres aléatoires pour garantir que le _id généré est unique. Lors de l'insertion en spécifiant _id, MongoDB doit vérifier si ce _id est disponible à chaque fois qu'il insère une donnée. Lorsqu'il y a trop d'éléments de données dans la base de données, la surcharge de requête de cette étape ralentira la vitesse d'insertion de l'ensemble. base de données.

3. MongoDB utilisera entièrement la mémoire système comme cache, ce qui est une très excellente fonctionnalité. Notre machine de test dispose de 64 Go de mémoire lors de l'insertion, MongoDB fera de son mieux pour conserver les données sur le disque dur une fois que la mémoire est presque pleine de données. C'est aussi la raison pour laquelle MongoDB est beaucoup plus efficace lors de l'insertion sans spécifier _id. Cependant, lors de l'insertion en spécifiant _id, lorsque la quantité de données est trop importante pour tenir dans la mémoire, MongoDB doit lire les informations du disque dans la mémoire pour vérifier la duplication, ce qui ralentit l'efficacité de l'insertion.

4. MySQL est en effet une base de données très stable. Peu importe que la clé primaire soit spécifiée ou insérée sans spécifier la clé primaire, son efficacité n'est pas très différente.

Analyse de la stabilité de l'insertion

La stabilité de l'insertion fait référence au taux d'insertion lorsqu'une certaine quantité de données est insérée à mesure que la quantité de données augmente.

Dans ce test, nous avons fixé l'échelle de cet indicateur à 100 000, c'est-à-dire que les données affichées correspondent au nombre de données pouvant être insérées par seconde pendant cette période lorsque 100 000 données sont insérées.

Présentez d'abord quatre images :

1 MongoDB spécifie l'insertion de _id :

2. >

3. MySQL spécifie la CLÉ PRIMAIRE pour l'insertion :

4. MySQL ne spécifie pas la CLÉ PRIMAIRE pour l'insertion :

Résumé :

1. La vitesse d'insertion globale est toujours similaire aux statistiques de l'épisode précédent : MongoDB ne spécifie pas _id pour l'insertion> MySQL ne spécifie pas la clé primaire pour l'insertion> MySQL spécifie la clé primaire pour l'insertion>

2. Comme le montre la figure, lors de l'insertion de données en spécifiant la clé primaire, lorsque MySQL et MongoDB ont des ordres de grandeur de données différents, les données insérées par seconde fluctuent de temps en temps. le graphique L'affichage devient des problèmes réguliers. Lorsque l'insertion de données n'est pas spécifiée, le taux d'insertion est relativement moyen dans la plupart des cas. Cependant, à mesure que les données dans la base de données augmentent, l'efficacité de l'insertion diminue momentanément au cours d'une certaine période de temps, puis redevient stable.

3. Dans l'ensemble, la fluctuation des taux de MongoDB est plus importante que celle de MySQL et la variance change de manière significative.

4. Lorsque MongoDB insère en spécifiant _id, lorsque plus de données sont insérées, l'efficacité de l'insertion diminue considérablement. Dans les trois autres tests d'insertion, le taux d'insertion est fixé à un standard la plupart du temps du début à la fin.

Analyse :

1. Le phénomène de problème est dû au fait que lorsque trop de données sont insérées, MongoDB doit écrire les données de la mémoire sur le disque dur et MySQL. doit être réécrit. Ces opérations sont effectuées automatiquement chaque fois que les données de la base de données atteignent un certain niveau, il y aura donc un problème évident de temps en temps.

2. MongoDB est encore une nouveauté après tout, et sa stabilité n'est pas aussi bonne que MySQL, qui est utilisé depuis de nombreuses années.

3. Lorsque MongoDB insère le _id spécifié, ses performances diminuent considérablement.

4. Lorsque la taille des données lues n'est pas grande, la vitesse de requête de MongoDB est vraiment inégalée, loin derrière MySQL.

5. À mesure que la quantité de données interrogées augmente progressivement, la vitesse de requête de MySQL diminue régulièrement, tandis que la vitesse de requête de MongoDB fluctue quelque peu.

Analyse :

1 Si MySQL n'a pas été optimisé pour les requêtes, sa vitesse de requête ne doit pas être comparée à MongoDB. MongoDB peut utiliser pleinement les ressources mémoire du système.Notre machine de test dispose de 64 Go de mémoire.Plus la mémoire est grande, plus la vitesse de requête de MongoDB est rapide.Après tout, l'efficacité des E/S du disque et de la mémoire n'est pas du même ordre de grandeur. .

2. Les données de requête dans cette expérience sont également générées de manière aléatoire, donc la probabilité que toutes les données à interroger soient stockées dans le cache mémoire de MongoDB est très faible. Lors de l'interrogation, MongoDB doit interagir plusieurs fois avec les données en mémoire et sur le disque afin de les trouver, son taux d'interrogation dépend donc du nombre d'interactions. Il est possible que, même si la quantité de données à interroger soit plus importante, ces données générées aléatoirement soient récupérées du disque par MongoDB un plus petit nombre de fois. Par conséquent, la vitesse moyenne des requêtes est plus rapide. De ce point de vue, les fluctuations de la vitesse des requêtes de MongoDB se situent également dans une fourchette raisonnable.

3. Il n'y a aucun doute sur la stabilité de MySQL.

Conclusion

1 Par rapport à MySQL, la base de données MongoDB est plus adaptée aux modèles de tâches avec des opérations de lecture lourdes. MongoDB peut utiliser pleinement les ressources mémoire de la machine. Si la machine dispose de ressources mémoire abondantes, l'efficacité des requêtes de MongoDB sera beaucoup plus rapide.

2. Lors de l'insertion de données avec "_id", l'efficacité d'insertion de MongoDB n'est en fait pas élevée. Si vous souhaitez exploiter pleinement les performances de MongoDB, il est recommandé d'insérer sans "_id", puis d'indexer les champs pertinents pour la requête.

3. MongoDB convient aux modèles de demande dans lesquels le format de données spécifique de la base de données n'est pas clair ou le format des données de la base de données change fréquemment, et il est très convivial pour les développeurs.

4. MongoDB est officiellement livré avec un système de fichiers distribué, qui peut être facilement déployé sur un cluster de serveurs. Il existe un concept de Shard dans MongoDB, qui est pratique pour le partitionnement de serveur. Avec chaque fragment supplémentaire, les performances d'insertion de MongoDB doubleront presque et la capacité du disque pourra également être facilement étendue.

5. MongoDB prend également en charge le framework informatique map-reduce, qui est également très pratique pour les statistiques de données.

Défauts de MongoDB

1. Faible prise en charge des relations de transaction. Il s'agit également d'un défaut commun à toutes les bases de données NoSQL. Cependant, NoSQL n'est pas conçu pour les relations transactionnelles et est toujours demandé pour des applications spécifiques.

2. La stabilité fait quelque peu défaut, comme le montre le test ci-dessus.

3. D'une part, MongoDB est pratique pour les développeurs, mais d'autre part, il impose des exigences considérables au personnel d'exploitation et de maintenance. Il n'y a pas d'expérience mature en matière d'exploitation et de maintenance de MongoDB dans l'industrie, et le format de stockage des données dans MongoDB est également très aléatoire. Des problèmes comme ceux-ci constituent un test pour le personnel d'exploitation et de maintenance.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!