Es ampliamente mencionado que Redis es «ultra Rápida» y mongoDB es demasiado rápido. Pero, estoy teniendo problemas para encontrar los números reales comparando los resultados de los dos. Dado configuraciones similares, características y operaciones (y tal vez mostrando cómo el factor de cambios con diferentes configuraciones y operaciones), etc, es Redis 10x más rápido?, 2x más rápido?, 5x más rápido?

SÓLO estoy hablando de rendimiento. Entiendo que mongoDB es una herramienta diferente y tiene un rico conjunto de características. Este no es el «Es mongoDB mejor de Redis» el debate. Yo estoy pidiendo, por lo que el margen no Redis superar a mongoDB?

En este punto, incluso hoteles de puntos de referencia son mejor que la ausencia de puntos de referencia.

  • Hoteles de puntos de referencia son siempre mejor que la ausencia de puntos de referencia. Gracias por la pregunta de su compañero.
  • En general, el cuidado acerca de la diferencia entre 5.000 ops/seg y 10.000 ops/seg es a menudo un caso de la optimización. Dicho esto, es todavía una interesante respuesta 🙂
InformationsquelleAutor Homer6 | 2011-03-09

7 Comentarios

  1. 228

    Bruto de resultados de la siguiente referencia: grabación 2x, 3x leer.

    Aquí es un simple punto de referencia en python que usted puede adaptar a sus propósitos, yo estaba mirando lo bien que cada uno iba a realizar un ajuste sencillo/recuperar valores:

    #!/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 __name__ == '__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)

    Resultados para con mongodb 1.8.1 y redis 2.2.5 y última 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

    A tomar los resultados con un grano de sal, por supuesto! Si desea programar en otro lenguaje, el uso de otros clientes/diferentes implementaciones, etc sus resultados pueden variar wildy. Por no hablar de su uso será completamente diferente! Su mejor apuesta es punto de referencia a ti mismo, exactamente de la manera que se pretendan hacer uso de ellos. Como corolario probablemente tendrás que averiguar el mejor manera de hacer uso de cada uno. Siempre punto de referencia para ti!

    • Muchas gracias… esto me da el estadio respuesta que yo estaba buscando… grabación 2x, 3x leer… perfecto… por supuesto, para problemas específicos, que va a ser diferente, pero esta es una estimación aproximada… tyvm
    • Vale la pena comentar que MongoDB y Redis tienen diferentes persistencia de las estructuras, y que Redis sólo admite un esquema de datos que es capaz de caber en la memoria. A pesar de que la memoria ram es barata, si usted necesita usar/tienda de más de 12-16 gb de datos, me gustaría ver lo que sus opciones de servidor aspecto.
    • Por lo tanto el «yo entiendo que mongoDB es una herramienta diferente». Cualquier número de factores que pueden cambiar el tiempo de acceso para una aplicación dada. Esta fue sólo la intención de ser un simple punto de referencia en el más fundamental de las estructuras de datos. Si te gustaría contribuir con una más exhaustiva de referencia, estoy seguro de que otros se beneficiarían de ella. Por favor, enlace a ella, si lo hace. Thx.
    • este post va desde la ausencia de puntos de referencia que claramente «en bruto» de referencia. No ser un troll con los «puntos de referencia son engañosas» tonterías. Por supuesto, diferentes condiciones pueden alterar los resultados. Contribuir a la comunidad y presentar sus propios puntos de referencia que probar su caso y el enlace de este post en lugar de eso, nos encargaremos de todos los beneficios de su «prueba» de opinión.
    • queridos homer6, admito que era demasiado dura, lo siento. Pero la red está llena de puntos de referencia con el valor de DB configuraciones y el moderno DB fabricantes de tomar la ventaja de que mediante el envío de sus productos con todos los sane opciones ajustado para el desempeño, más que en la seguridad. Imaginar postgres envío con synchronous_commit=off, que sería ridículo para ellos ya que imposibilitaría la durabilidad. Hacer algo como eso, en realidad puntos de referencia del bus de la memoria y de la red no a la DB.
    • El valor predeterminado (enviado) configuración es lo que este punto de referencia era la prueba. En mi humilde opinión, la configuración predeterminada determina qué lado de la fsync valla de un paquete se encuentra. Para Redis, es anunciado como un servidor de memoria que insta a la gente a usar otras alternativas cuando la base de datos es mayor que el total de memoria del sistema. Para MongoDB, es anunciado como una base de datos. Postgres no se apagará nunca fsync porque están claramente en la persistencia del campamento. La mayoría de la gente no modificar las configuraciones, por lo que este punto de referencia es algo preciso para esos casos.
    • Para más información: redis.io/temas/persistencia o oldblog.antirez.com/post/redis-persistence-demystified.html
    • Estoy de acuerdo con @sivann, el punto de referencia que has publicado es fatalmente, es deficiente. MongoDB es multi-hilo y Redis no lo es. Si el punto de referencia era multi-threaded, verá que MongoDb en realidad tiene un mayor rendimiento en un multi-núcleo de la máquina.
    • incluso para la memoria orientada a la DB, se debe hacer la prueba con WriteConcern activado (por defecto desactivado). Pruebas sin realmente es una tontería para cualquier tipo de punto de referencia. Similares para reddis. DBs que no se sincronizan en el disco todas las transacciones, mantener la seguridad mediante la replicación de los datos de al menos 2 servidores. Eso significa que sus escrituras no espere a que un disco de sincronización, pero para la replicación de red antes de regresar. No espera que de los errores es algo nunca hecho en prod. como no detectar si el cable de red está conectado al escribir en la red.
    • El valor predeterminado cambiado. docs.mongodb.org/manual/release-notes/drivers-write-concern
    • Redis resultados serían mucho mejores si se utiliza hiredis módulo. Para el código de python evaluación es mejor usar timeit módulo. Saludos.

  2. 17

    Por favor, compruebe este post sobre Redis y MongoDB rendimiento de la inserción de análisis:

    Hasta 5000 entradas mongodb $empuje es más rápido incluso cuando se compara con Redis RPUSH, entonces resulta increíblemente lento, probablemente la mongodb matriz de tipo lineal inserción de tiempo y por lo que se vuelve más lento y más lento. mongodb puede ganar un poco de actuaciones de la exposición de una constante de tiempo de la inserción de la lista tipo, pero incluso con el tiempo lineal de la matriz de tipo (que puede garantizar una constante de tiempo de búsqueda) tiene sus aplicaciones para pequeños conjuntos de datos.

  3. 15

    Buena y sencilla de referencia

    Traté de volver a calcular de nuevo los resultados utilizando las versiones actuales de redis(2.6.16) y mongo(2.4.8) y aquí está el resultado

    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

    También esta blog compara tanto de ellos, pero el uso de node.js. Muestra el efecto de aumentar el número de entradas en la base de datos junto con el tiempo.

  4. 7

    Números van a ser difíciles de encontrar ya que los dos no están del todo en el mismo espacio. La respuesta general es que Redis 10 – 30% más rápido cuando el conjunto de datos se ajusta dentro de la memoria de trabajo de una sola máquina. Una vez que la cantidad de datos que se supera, Redis falla. Mongo se ralentizará en una cantidad que depende del tipo de carga. Para insertar un único tipo de carga de un usuario informado recientemente de una desaceleración de 6 a 7 órdenes de magnitud (de 10.000 a 100.000 veces) pero ese informe también admitió que había problemas de configuración, y que esto era muy atípico de carga de trabajo. Normal leer cargas pesadas como anécdota lento por cerca de 10 VECES cuando algunos de los datos se leen desde el disco.

    Conclusión: Redis será más rápido, pero no por mucho.

  5. 7

    Aquí es un excelente artículo acerca de sesión rendimiento en el Tornado marco alrededor de 1 año de edad. Tiene una comparación entre un par de implementaciones diferentes, de los cuales Redis y MongoDB están incluidos. El gráfico en el artículo se dice que Redis está detrás de MongoDB alrededor de un 10% en este caso de uso específico.

    Redis viene con un sistema incorporado en la referencia que se va a analizar el rendimiento de la máquina que usted está en. Hay un montón de datos sin procesar de la misma en el Punto de referencia de la wiki para Redis. Pero usted tendría que mirar un poco alrededor para Mongo. Como aquí, aquí, y algunos al azar polaco números (pero le da un punto de partida para la ejecución de algunos de MongoDB puntos de referencia a sí mismo).

    Creo que la mejor solución a este problema es realizar las pruebas a ti mismo en los tipos de situaciones que esperar.

    • El Tornado puntos de referencia se alinea bien con mis propias pruebas en el uso de Redis y MongoDb como Zend_Cache backend. La funcionalidad más completa de MongoDb permite utilizar menos solicitudes y el diseño multihilo escalas mucho mejor que una sola Redis proceso que no es multi-threaded. La conclusión es que MongoDb escalas mayores. También, Redis ya no es compatible con la memoria virtual.
  6. 3

    En mi caso, lo que ha sido un factor determinante en el rendimiento de la comparación, es la MongoDb WriteConcern que se utiliza. La mayoría de mongo los conductores de hoy en día va a establecer el valor predeterminado de WriteConcern para RECONOCIÓ que significa «escrito a RAM» ( Mongo2.6.3-WriteConcern ), en la que se refiere, es muy comparable a la de redis para la mayoría de las operaciones de escritura.

    Pero la realidad es que dependiendo de las necesidades de su aplicación y entorno de producción de la instalación, es posible que desee cambiar esta preocupación a la WriteConcern.En el DIARIO (escrito a oplog) o WriteConcern.FSYNCED (escrito a disco), o incluso por escrito a los conjuntos de réplicas (back-ups) si es necesario.

    Entonces usted puede empezar a ver algunos disminución del rendimiento. Otros factores importantes incluyen también, cómo optimizado el acceso a los datos de patrones, el índice de miss % (ver mongostat) y los índices en general.

  7. 0

    Creo que la 2-3X en la muestra de referencia son engañosas, ya que si usted también depende del hardware que se ejecuta en – desde mi experiencia, el ‘más fuerte’ de la máquina, mayor es la brecha (en favor de Redis) será,
    probablemente por el hecho de que el punto de referencia golpea la memoria de los límites límite bastante rápido.

    Como para la capacidad de la memoria – esto es parcialmente cierto, ya que también hay formas de ir alrededor de eso, hay (comercial) de los productos que escribe Redis de datos en el disco, y también de clúster (multi-sharded) soluciones que superen la memoria limitación de tamaño.

Dejar respuesta

Please enter your comment!
Please enter your name here