Il est largement mentionné que Redis est "Blazing Fast" et que mongoDB est rapide aussi. Mais j'ai du mal à trouver les chiffres réels en comparant les résultats des deux. Avec des configurations, des fonctionnalités et des opérations similaires (et montrant peut-être comment le facteur change avec différentes configurations et opérations), etc., Redis est-il 10x plus rapide?, 2x plus rapide?, 5x plus rapide?
Je ne parle que de performance. Je comprends que mongoDB est un outil différent et possède un ensemble de fonctionnalités plus riche. Ce n'est pas le débat "Est-ce que mongoDB mieux que Redis". Je demande, dans quelle mesure Redis surpasse-t-il mongoDB?
À ce stade, même les points de repère les moins chers valent mieux que pas de points de repère.
Résultats approximatifs du point de référence suivant: 2x write, 3x read .
Voici un repère simple en python que vous pouvez adapter à vos objectifs. J'examinais à quel point chacun effectuerait simplement la définition/récupération de valeurs:
#!/usr/bin/env python2.7
import sys, time
from pymongo import Connection
import redis
# connect to redis & mongodb
redis = redis.Redis()
mongo = Connection().test
collection = mongo['test']
collection.ensure_index('key', unique=True)
def mongo_set(data):
for k, v in data.iteritems():
collection.insert({'key': k, 'value': v})
def mongo_get(data):
for k in data.iterkeys():
val = collection.find_one({'key': k}, fields=('value',)).get('value')
def redis_set(data):
for k, v in data.iteritems():
redis.set(k, v)
def redis_get(data):
for k in data.iterkeys():
val = redis.get(k)
def do_tests(num, tests):
# setup dict with key/values to retrieve
data = {'key' + str(i): 'val' + str(i)*100 for i in range(num)}
# run tests
for test in tests:
start = time.time()
test(data)
elapsed = time.time() - start
print "Completed %s: %d ops in %.2f seconds : %.1f ops/sec" % (test.__name__, num, elapsed, num / elapsed)
if __== '__main__':
num = 1000 if len(sys.argv) == 1 else int(sys.argv[1])
tests = [mongo_set, mongo_get, redis_set, redis_get] # order of tests is significant here!
do_tests(num, tests)
Résultats pour avec mongodb 1.8.1 et redis 2.2.5 et le dernier pymongo/redis-py:
$ ./cache_benchmark.py 10000
Completed mongo_set: 10000 ops in 1.40 seconds : 7167.6 ops/sec
Completed mongo_get: 10000 ops in 2.38 seconds : 4206.2 ops/sec
Completed redis_set: 10000 ops in 0.78 seconds : 12752.6 ops/sec
Completed redis_get: 10000 ops in 0.89 seconds : 11277.0 ops/sec
Prenez les résultats avec un grain de sel bien sûr! Si vous programmez dans un autre langage, utilisez d'autres clients/implémentations différentes, etc., vos résultats seront variables. Sans parler de votre utilisation sera complètement différente! Votre meilleur pari est de les comparer vous-même, précisément de la manière dont vous avez l’intention de les utiliser. En corollaire, vous découvrirez probablement le meilleur moyen de les utiliser. Toujours une référence pour vous-même!
Veuillez vérifier ce message à propos de l'analyse des performances d'insertion de Redis et MongoDB:
Jusqu'à 5 000 entrées mongodb $ Push est plus rapide, même par rapport à Redis RPUSH, alors il est devenu incroyablement lent, probablement le type de tableau mongodb a un temps d'insertion linéaire et devient donc de plus en plus lent. mongodb peut gagner un peu en performances en exposant un type de liste d'insertion en temps constant, mais même avec le type tableau linéaire en temps (qui peut garantir une recherche en temps constant), il a ses applications pour de petits ensembles de données.
Bon et simple repère
J'ai essayé de recalculer les résultats à nouveau en utilisant les versions actuelles de Redis (2.6.16) et de Mongo (2.4.8) et voici le résultat
Completed mongo_set: 100000 ops in 5.23 seconds : 19134.6 ops/sec
Completed mongo_get: 100000 ops in 36.98 seconds : 2703.9 ops/sec
Completed redis_set: 100000 ops in 6.50 seconds : 15389.4 ops/sec
Completed redis_get: 100000 ops in 5.59 seconds : 17896.3 ops/sec
De plus, cet article blog compare les deux mais en utilisant node.js. Il montre l'effet du nombre croissant d'entrées dans la base de données avec le temps.
Les chiffres vont être difficiles à trouver car les deux ne sont pas tout à fait dans le même espace. La réponse générale est que Redis est 10 à 30% plus rapide lorsque le jeu de données s'inscrit dans la mémoire de travail d'un seul ordinateur. Une fois que cette quantité de données est dépassée, Redis échoue. Mongo va ralentir à un montant qui dépend du type de charge. Pour un type de charge insérée uniquement, un utilisateur a récemment signalé un ralentissement de l'ordre de 6 à 7 ordres de grandeur (10 000 à 100 000 fois), mais ce rapport a également admis l'existence de problèmes de configuration et qu'il s'agissait d'une charge de travail très atypique. La lecture normale de lourdes charges de manière anecdotique est lente d’environ 10 fois lorsque certaines données doivent être lues à partir du disque.
Conclusion: Redis sera plus rapide mais pas de beaucoup.
Voici un excellent article sur performance de session dans le framework Tornado âgé d’un an environ. Il présente une comparaison entre quelques implémentations différentes, parmi lesquelles Redis et MongoDB sont incluses. Le graphique dans l'article indique que Redis est d'environ 10% inférieur à MongoDB par rapport à ce cas d'utilisation spécifique.
Redis est livré avec un benchmark intégré qui analysera les performances de la machine sur laquelle vous vous trouvez. Il existe une tonne de données brutes à partir de Benchmark wiki for Redis. Mais vous devrez peut-être chercher un peu autour de Mongo. Comme ici , ici et des nombres aléatoires polonais (mais cela vous donne un point de départ pour exécuter vous-même des points de repère MongoDB).
Je pense que la meilleure solution à ce problème consiste à effectuer les tests vous-même dans les types de situations que vous attendez.
Dans mon cas, le facteur déterminant dans la comparaison des performances est le MongoDb WriteConcern utilisé. De nos jours, la plupart des drivers mongo attribueront à ACCELLOWLEDGED le code par défaut WriteConcern, ce qui signifie "écrit en RAM" ( Mongo2.6.3-WriteConcern ), en ce sens qu'il était très comparable à redis pour la plupart des opérations d'écriture.
Toutefois, en réalité, en fonction des besoins de votre application et de la configuration de votre environnement de production, vous pouvez modifier ce problème en WriteConcern.JOURNALED (écrit dans oplog) ou WriteConcern.FSYNCED (écrit sur le disque) ou même écrit sur des jeux de réplicas (sauvegardes). si c'est nécessaire.
Ensuite, vous pouvez commencer à voir une baisse de performance. D'autres facteurs importants incluent également l'optimisation de vos schémas d'accès aux données, l'index% de ratés (voir mongostat ) et les index en général.
Je pense que les 2-3X sur le repère indiqué sont trompeurs, car si vous dépendez également du matériel sur lequel vous l'exécutez - de mon expérience, plus la machine est "forte", plus l'écart est grand (en faveur de Redis) sera probablement dû au fait que le point de repère atteint rapidement la limite de mémoire.
En ce qui concerne la capacité de la mémoire - cela est partiellement vrai, car il existe également des solutions, il existe des produits (commerciaux) qui écrivent les données Redis sur disque, ainsi que des solutions en cluster (multi-sharded) qui dépassent la taille de la mémoire. limitation.