MySQL vs MongoDB 1000 lectures

J’ai été très enthousiasmé par MongoDb et je l’ai testé récemment. J’avais une table appelée posts dans MySQL avec environ 20 millions d’enregistrements indexés uniquement sur un champ appelé “id”.

Je voulais comparer la vitesse avec MongoDB et j’ai effectué un test qui obtiendrait et imprimerait au hasard 15 enregistrements de nos énormes bases de données. J’ai exécuté la requête environ 1000 fois chacune pour mysql et MongoDB et je suis surpris que je ne remarque pas beaucoup de différence de vitesse. Peut-être que MongoDB est 1,1 fois plus rapide. C’est très décevant. Y a-t-il quelque chose que je fais mal? Je sais que mes tests ne sont pas parfaits, mais MySQL est à la hauteur de MongoDb quand il s’agit de lire des tâches intensives.

Remarque:

  • J’ai des processeurs dual core + (2 threads) i7 et 4 Go
  • J’ai 20 partitions sur MySQL de 1 million d’enregistrements

Exemple de code utilisé pour tester MongoDB

<?php function microtime_float() { list($usec, $sec) = explode(" ", microtime()); return ((float)$usec + (float)$sec); } $time_taken = 0; $tries = 100; // connect $time_start = microtime_float(); for($i=1;$iswalif; $cursor = $db->posts->find(array('id' => array('$in' => get_15_random_numbers()))); foreach ($cursor as $obj) { //echo $obj["thread_title"] . "

"; } } $time_end = microtime_float(); $time_taken = $time_taken + ($time_end - $time_start); echo $time_taken; function get_15_random_numbers() { $numbers = array(); for($i=1;$i

Exemple de code pour tester MySQL

 <?php function microtime_float() { list($usec, $sec) = explode(" ", microtime()); return ((float)$usec + (float)$sec); } $BASE_PATH = "../src/"; include_once($BASE_PATH . "classes/forumdb.php"); $time_taken = 0; $tries = 100; $time_start = microtime_float(); for($i=1;$iexecuteSQL($sql); while ($row = mysql_fetch_array($result) ) { //echo $row["thread_title"] . "

"; } } $time_end = microtime_float(); $time_taken = $time_taken + ($time_end - $time_start); echo $time_taken; function get_15_random_numbers() { $numbers = array(); for($i=1;$i

MongoDB n’est pas magiquement plus rapide. Si vous stockez les mêmes données, organisées de la même manière et y accédez exactement de la même manière, vous ne devriez pas vous attendre à des résultats très différents. Après tout, MySQL et MongoDB sont tous deux des GPL, donc si Mongo avait un code d’E / S magiquement meilleur, alors l’équipe MySQL pourrait simplement l’incorporer dans leur base de code.

Les gens voient les performances réelles de MongoDB en grande partie parce que MongoDB vous permet d’interroger d’une manière différente, plus sensible à votre charge de travail.

Par exemple, considérez une conception qui contenait beaucoup d’informations sur une entité compliquée de manière normalisée. Cela pourrait facilement utiliser des dizaines de tables dans MySQL (ou toute firebase database 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 le même design avec un magasin de documents. Si toutes les tables associées sont subordonnées à la table principale (et elles le sont souvent), vous pourrez peut-être modéliser les données de manière à ce que l’entité entière soit stockée dans un seul document. Dans MongoDB, vous pouvez stocker ceci en un seul document, dans une seule collection. C’est là que MongoDB commence à offrir des performances supérieures.

Dans MongoDB, pour récupérer l’entité entière, vous devez effectuer:

  • Une recherche d’index sur la collection (en supposant que l’entité soit extraite par l’ID)
  • Récupérer le contenu d’une page de firebase database (le document json binary réel)

Donc, une recherche B-Tree et une page binary lue. Log (n) + 1 E / S. Si les index peuvent résider entièrement en mémoire, alors 1 IO.

En MySQL avec 20 tables, vous devez effectuer:

  • Une recherche d’index sur la table racine (encore une fois, en supposant que l’entité est récupérée par id)
  • Avec un index clusterisé, on peut supposer que les valeurs de la ligne racine sont dans l’index
  • 20+ plages de recherche (sur un index, espérons-le) pour la valeur pk de l’entité
  • Celles-ci ne sont probablement pas des index clusterisés, donc les mêmes 20 + recherches de données une fois que nous déterminons quelles sont les lignes enfant appropriées.

Donc, le total pour mysql, même en supposant que tous les index sont en mémoire (ce qui est plus difficile puisqu’il y en a 20 fois plus) est d’environ 20 recherches de plage.

Ces recherches d’intervalles sont probablement composées d’E / S aléatoires – différentes tables se trouveront définitivement à différents endroits sur le disque, et il est possible que différentes lignes de la même plage d’une même table ne soient pas contiguës (en fonction de mis à jour, etc.).

Donc, pour cet exemple, le décompte final est environ 20 fois plus IO avec MySQL par access logique, comparé à MongoDB.

C’est ainsi que MongoDB peut améliorer les performances dans certains cas d’utilisation .

Avez-vous des access simultanés, c.-à-d. Des utilisateurs simultanés? Si vous exécutez 1000 fois la requête directement, avec un seul thread, il n’y aura presque aucune différence. Trop facile pour ces moteurs 🙂

MAIS je suggère fortement que vous construisiez une véritable session de test de charge, ce qui signifie que vous devez utiliser un injecteur tel que JMeter avec 10, 20 ou 50 utilisateurs EN MÊME TEMPS pour que vous puissiez vraiment voir la différence (essayez d’intégrer ce code dans une page Web). pourrait interroger).

Je viens de le faire aujourd’hui sur un seul serveur (et une simple collection / table) et les résultats sont assez intéressants et surprenants (MongoDb était vraiment plus rapide sur les écritures et les lectures, comparé au moteur MyISAM et au moteur InnoDb).

Cela devrait vraiment faire partie de votre test: simultanéité et moteur MySQL. Ensuite, la conception des données / schémas et les besoins en applications sont bien sûr des exigences énormes, au-delà des temps de réponse. Faites-moi savoir quand vous obtenez des résultats, j’ai aussi besoin de consortingbutions à ce sujet!

Source: https://github.com/webcaetano/mongo-mysql

10 lignes

 mysql insert: 1702ms mysql select: 11ms mongo insert: 47ms mongo select: 12ms 

100 lignes

 mysql insert: 8171ms mysql select: 10ms mongo insert: 167ms mongo select: 60ms 

1000 lignes

 mysql insert: 94813ms (1.58 minutes) mysql select: 13ms mongo insert: 1013ms mongo select: 677ms 

10.000 lignes

 mysql insert: 924695ms (15.41 minutes) mysql select: 144ms mongo insert: 9956ms (9.95 seconds) mongo select: 4539ms (4.539 seconds) 

man ,, la réponse est que vous testez essentiellement PHP et non une firebase database.

ne vous embêtez pas à répéter les résultats, qu’ils soient commentés ou non. il y a beaucoup de temps.

  foreach ($cursor as $obj) { //echo $obj["thread_title"] . "

"; }

tandis que l’autre partie est dépenser un tas de nombres de rand.

 function get_15_random_numbers() { $numbers = array(); for($i=1;$i<=15;$i++) { $numbers[] = mt_rand(1, 20000000) ; } return $numbers; } 

puis il y a une différence majeure avec l'implosion

et enfin ce qui se passe ici. ressemble à créer une connexion à chaque fois, donc il teste le temps de connexion plus le temps de la requête.

 $m = new Mongo(); 

contre

 $db = new AQLDatabase(); 

Ainsi, votre requête 101% plus rapide peut s'avérer 1000% plus rapide pour la requête sous-jacente dépouillée du jazz.

urghhh.

https://github.com/reoxey/benchmark

référence

Comparaison rapide de MySQL & MongoDB dans GOLANG1.6 et PHP5

système utilisé pour le benchmark: DELL cpu i5 4ème génération 1.70 GHz * 4 RAM 4 Go GPU ram 2 Go

Comparaison de vitesse de SGBDR vs NoSQL pour INSERT, SELECT, UPDATE, DELETE exécutant un nombre différent de lignes 10,100,1000,10000,100000,1000000

La langue utilisée pour exécuter est: PHP5 & Google langue la plus rapide GO 1.6

 ________________________________________________ GOLANG with MySQL (engine = MyISAM) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ INSERT ------------------------------------------------ num of rows time taken ------------------------------------------------ 10 1.195444ms 100 6.075053ms 1000 47.439699ms 10000 483.999809ms 100000 4.707089053s 1000000 49.067407174s SELECT ------------------------------------------------ num of rows time taken ------------------------------------------------ 1000000 872.709µs SELECT & DISPLAY ------------------------------------------------ num of rows time taken ------------------------------------------------ 1000000 20.717354746s UPDATE ------------------------------------------------ num of rows time taken ------------------------------------------------ 1000000 2.309209968s 100000 257.411502ms 10000 26.73954ms 1000 3.483926ms 100 915.17µs 10 650.166µs DELETE ------------------------------------------------ num of rows time taken ------------------------------------------------ 1000000 6.065949ms ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ________________________________________________ GOLANG with MongoDB ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ INSERT ------------------------------------------------ num of rows time taken ------------------------------------------------ 10 2.067094ms 100 8.841597ms 1000 106.491732ms 10000 998.225023ms 100000 8.98172825s 1000000 1m 29.63203158s SELECT ------------------------------------------------ num of rows time taken ------------------------------------------------ 1000000 5.251337439s FIND & DISPLAY (with index declared) ------------------------------------------------ num of rows time taken ------------------------------------------------ 1000000 21.540603252s UPDATE ------------------------------------------------ num of rows time taken ------------------------------------------------ 1 1.330954ms ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ________________________________________________ PHP5 with MySQL (engine = MyISAM) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ INSERT ------------------------------------------------ num of rows time taken ------------------------------------------------ 10 0.0040680000000001s 100 0.011595s 1000 0.049718s 10000 0.457164s 100000 4s 1000000 42s SELECT ------------------------------------------------ num of rows time taken ------------------------------------------------ 1000000 <1s SELECT & DISPLAY ------------------------------------------------ num of rows time taken ------------------------------------------------ 1000000 20s ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ________________________________________________ PHP5 with MongoDB ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ INSERT ------------------------------------------------ num of rows time taken ------------------------------------------------ 10 0.065744s 100 0.190966s 1000 0.2163s 10000 1s 100000 8s 1000000 78s FIND ------------------------------------------------ num of rows time taken ------------------------------------------------ 1000000 <1s FIND & DISPLAY ------------------------------------------------ num of rows time taken ------------------------------------------------ 1000000 7s UPDATE ------------------------------------------------ num of rows time taken ------------------------------------------------ 1000000 9s 

Voici une petite recherche qui a exploré le SGBDR vs NoSQL en utilisant MySQL vs Mongo, les conclusions étaient en ligne avec la réponse de @Sean Reilly. En bref, le bénéfice provient de la conception, et non d’une différence de vitesse brute. Conclusion page 35-36:

SGBDR vs NoSQL: Comparaison des performances et de la mise à l’échelle

Le projet a testé, analysé et comparé les performances et l’évolutivité des deux types de firebase database. Les expériences effectuées comprenaient l’exécution de différents nombres et types de requêtes, certaines plus complexes que d’autres, afin d’parsingr la façon dont les bases de données évoluaient avec une charge accrue. Le facteur le plus important dans ce cas était le type de requête utilisé car MongoDB pouvait traiter plus rapidement des requêtes plus complexes, principalement en raison de son schéma plus simple, au désortingment de la duplication des données, ce qui signifie qu’une firebase database NoSQL peut contenir de grandes quantités de doublons. Bien qu’un schéma directement migré à partir du SGBDR puisse être utilisé, cela éliminerait l’avantage de la représentation sous-jacente des données des sous-documents par MongoDB, ce qui permettrait d’utiliser moins de requêtes vers la firebase database lorsque les tables étaient combinées. Malgré le gain de performances de MongoDB par rapport à MySQL dans ces requêtes complexes, le benchmark modélisait la requête MySQL de la même manière que la requête complexe MongoDB en utilisant des requêtes SELECT nestedes MySQL se comportait de la même manière. Le dernier type de requête référencé qui était la requête complexe contenant deux JOINS et une sous-requête a montré l’avantage que MongoDB a sur MySQL en raison de l’utilisation de sous-documents. Cet avantage se fait au désortingment de la duplication des données, ce qui entraîne une augmentation de la taille de la firebase database. Si de telles requêtes sont courantes dans une application, il est important de considérer les bases de données NoSQL comme des alternatives tout en tenant compte du coût de stockage et de la taille de la mémoire résultant de la taille plus importante de la firebase database.

Sur un serveur unique, MongoDb ne serait pas plus rapide que MySIS MyISAM en lecture et en écriture, les tailles de table / doc étant petites (1 à 20 Go).
MonoDB sera plus rapide sur Parallel Reduce sur les clusters multi-nœuds, où Mysql ne peut PAS évoluer horizontalement.