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 exécuté un test qui permettrait d'obtenir et d'imprimer 15 enregistrements au hasard à partir de nos énormes bases de données. J'ai exécuté la requête environ 1 000 fois chacune pour mysql et MongoDB et je suis surpris de ne pas remarquer 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 à égalité avec MongoDb quand il s'agit de lire des tâches intensives.
Remarque:
- J'ai dual core + (2 threads) i7 cpu et 4GB ram
- J'ai 20 partitions sur MySQL chacune 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;$i<=$tries;$i++)
{
$m = new Mongo();
$db = $m->swalif;
$cursor = $db->posts->find(array('id' => array('$in' => get_15_random_numbers())));
foreach ($cursor as $obj)
{
//echo $obj["thread_title"] . "<br><Br>";
}
}
$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<=15;$i++)
{
$numbers[] = mt_rand(1, 20000000) ;
}
return $numbers;
}
?>
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;$i<=$tries;$i++)
{
$db = new AQLDatabase();
$sql = "select * from posts_really_big where id in (".implode(',',get_15_random_numbers()).")";
$result = $db->executeSQL($sql);
while ($row = mysql_fetch_array($result) )
{
//echo $row["thread_title"] . "<br><Br>";
}
}
$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<=15;$i++)
{
$numbers[] = mt_rand(1, 20000000);
}
return $numbers;
}
?>la source
Réponses:
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 y accédez exactement de la même manière, alors vous ne devriez vraiment pas vous attendre à ce que vos résultats soient extrêmement différents. Après tout, MySQL et MongoDB sont tous deux GPL, donc si Mongo avait du code IO magiquement meilleur, alors l'équipe MySQL pourrait simplement l'incorporer dans leur 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érons une conception qui a persisté beaucoup d'informations sur une entité compliquée 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 forme normale, avec de nombreux index nécessaires pour assurer l'intégrité relationnelle entre les tables.
Considérez maintenant la même conception avec un magasin de documents. Si toutes ces tables associé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 tant que document unique, 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:
Donc une recherche de 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 E / S.
Dans MySQL avec 20 tables, vous devez effectuer:
Donc, 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 de 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 environ 20 fois plus d'E / S avec MySQL par accès logique, par rapport à MongoDB.
C'est ainsi que MongoDB peut augmenter les performances dans certains cas d'utilisation .
la source
Avez-vous des accès concurrents, c'est-à-dire des utilisateurs simultanés? Si vous exécutez simplement 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 vous suggère fortement de créer une véritable session de test de charge, ce qui signifie utiliser un injecteur tel que JMeter avec 10, 20 ou 50 utilisateurs EN MÊME TEMPS afin que vous puissiez vraiment voir une différence (essayez d'incorporer ce code dans une page Web JMeter 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 en écriture et en lecture, par rapport au moteur MyISAM et au moteur InnoDb).
Cela devrait vraiment faire partie de votre test: moteur d'accès simultané et MySQL. Ensuite, les besoins de conception / application de données / schémas sont bien sûr des exigences énormes, au-delà des temps de réponse. Faites-moi savoir lorsque vous obtenez des résultats, j'ai également besoin de commentaires à ce sujet!
la source
Source: https://github.com/webcaetano/mongo-mysql
10 rangées
100 rangées
1000 lignes
10.000 lignes
la source
man ,,, la réponse est que vous testez essentiellement PHP et non une base de données.
ne vous embêtez pas à répéter les résultats, que vous commentiez l'impression ou non. il y a beaucoup de temps.
tandis que l'autre morceau est de passer un tas de numéros de rand.
puis il y a une différence majeure n / b imploser et en.
et enfin ce qui se passe ici. ressemble à créer une connexion à chaque fois, testant ainsi le temps de connexion plus le temps de requête.
contre
donc votre 101% plus rapide pourrait s'avérer 1000% plus rapide pour la requête sous-jacente dépouillée de jazz.
urghhh.
la source
https://github.com/reoxey/benchmark
référence
comparaison de vitesse de MySQL et MongoDB dans GOLANG1.6 et PHP5
système utilisé pour le benchmark: DELL cpu i5 4th gen 1.70Ghz * 4 ram 4GB GPU ram 2GB
Comparaison de vitesse de RDBMS vs NoSQL pour INSERT, SELECT, UPDATE, DELETE exécutant différents nombres de lignes 10,100,1000,10000,100000,1000000
Le langage utilisé pour exécuter est: PHP5 et le langage le plus rapide de Google GO 1.6
la source
Voici une petite recherche qui a exploré RDBMS vs NoSQL en utilisant MySQL vs Mongo, les conclusions étaient conformes à la réponse de @Sean Reilly. En bref, l'avantage provient de la conception, pas d'une différence de vitesse brute. Conclusion à la page 35-36:
RDBMS vs NoSQL: comparaison des performances et de la mise à l'échelle
la source
Sur un seul serveur, MongoDb ne serait pas plus rapide que mysql MyISAM en lecture et en écriture, étant donné que les tailles de table / doc sont petites de 1 Go à 20 Go.
MonoDB sera plus rapide sur Parallel Reduce sur les clusters multi-nœuds, où Mysql ne peut PAS évoluer horizontalement.
la source