MongoDB n'est pas magiquement plus rapide. Si vous stockez les mêmes données, organisées essentiellement de la même manière, et que vous y accédez exactement de la même manière, vous ne devriez vraiment pas vous attendre à ce que vos résultats soient très différents. Après tout, MySQL et MongoDB sont tous deux GPL, donc si Mongo contenait un code IO magiquement meilleur, l'équipe MySQL pourrait simplement l'incorporer dans sa base de code.
Les gens voient les performances de MongoDB dans le monde réel en grande partie parce que MongoDB vous permet d'interroger d'une manière différente qui est plus sensible à votre charge de travail.
Par exemple, considérez une conception qui conserve de nombreuses informations sur une entité complexe de manière normalisée. Cela pourrait facilement utiliser des dizaines de tables dans MySQL (ou n'importe quelle base de données relationnelle) pour stocker les données sous une forme normale, avec de nombreux index nécessaires pour assurer l'intégrité relationnelle entre les tables.
Considérons maintenant la même conception avec un magasin de documents. Si toutes ces tables liées sont subordonnées à la table principale (et elles le sont souvent), vous pourrez peut-être modéliser les données de sorte que l'entité entière soit stockée dans un seul document. Dans MongoDB, vous pouvez stocker cela en un seul document, dans une seule collection. C'est là que MongoDB commence à permettre des performances supérieures.
Dans MongoDB, pour récupérer l'intégralité de l'entité, il faut effectuer :
- Une recherche d'index sur la collection (en supposant que l'entité est récupérée par identifiant)
- Récupérer le contenu d'une page de base de données (le document json binaire réel)
Donc, une recherche b-tree et une page binaire lue. Log(n) + 1 E/S. Si les index peuvent résider entièrement en mémoire, alors 1 IO.
Dans MySQL avec 20 tables, il faut effectuer :
- Une recherche d'index sur la table racine (là encore, en supposant que l'entité est récupérée par identifiant)
- Avec un index clusterisé, nous pouvons supposer que les valeurs de la ligne racine se trouvent dans l'index
- Plus de 20 recherches de plage (espérons-le sur un index) pour la valeur pk de l'entité
- Il ne s'agit probablement pas d'index clusterisés, donc les mêmes 20 recherches de données une fois que nous avons déterminé quelles sont les lignes enfants appropriées.
Ainsi, le total pour mysql, même en supposant que tous les index sont en mémoire (ce qui est plus difficile car il y en a 20 fois plus) est d'environ 20 recherches de plage.
Ces recherches de plage sont probablement composées d'E/S aléatoires - différentes tables résideront certainement à différents endroits sur le disque, et il est possible que différentes lignes dans la même plage dans la même table pour une entité ne soient pas contiguës (selon la façon dont l'entité a été mis à jour, etc.).
Donc, pour cet exemple, le décompte final est d'environ 20 fois plus d'E/S avec MySQL par accès logique, par rapport à MongoDB.
C'est ainsi que MongoDB peut améliorer les performances dans certains cas d'utilisation .
