Lo que quiero no es una comparación entre Redis y MongoDB. Sé que son diferentes. El rendimiento y la API es totalmente diferente.

Redis es muy rápido, pero la API es muy 'atómica'. MongoDB consumirá más recursos, pero la API es muy fácil de usar y estoy muy contento con ella.

Ambos son increíbles, y quiero usar Redis en la implementación tanto como pueda, pero es difícil de codificar. Quiero usar MongoDB en desarrollo tanto como pueda, pero necesita una máquina costosa.

Entonces, ¿qué opinas sobre el uso de ambos? ¿Cuándo elegir Redis? ¿Cuándo elegir MongoDB?

Diría que depende del tipo de equipo de desarrollo que sea y de las necesidades de su aplicación.

Por ejemplo, si requiere muchas consultas , eso significa principalmente que sería más trabajo para sus desarrolladores usar Redis, donde sus datos podrían almacenarse en una variedad de estructuras de datos especializadas, personalizadas para cada tipo de objeto para mayor eficiencia. En MongoDB, las mismas consultas podrían ser más fáciles porque la estructura es más consistente en todos sus datos. Por otro lado, en Redis, la gran velocidad de la respuesta a esas consultas es la recompensa por el trabajo adicional de lidiar con la variedad de estructuras con las que se pueden almacenar sus datos.

MongoDB ofrece simplicidad, una curva de aprendizaje mucho más corta para desarrolladores con experiencia tradicional en DB y SQL. Sin embargo, el enfoque no tradicional de Redis requiere más esfuerzo para aprender, pero una mayor flexibilidad.

P.ej. Una capa de caché probablemente se puede implementar mejor en Redis. Para obtener más datos con capacidad de esquema, MongoDB es mejor. [Nota: tanto MongoDB como Redis son técnicamente sin esquema]

Si me preguntas, mi elección personal es Redis para la mayoría de los requisitos.

Por último, espero que haya visto http://antirez.com/post/MongoDB-and-Redis.html

Acabo de notar que esta pregunta es bastante antigua. Sin embargo, considero que vale la pena agregar los siguientes aspectos:

• Use MongoDB si aún no sabe cómo va a consultar sus datos.

  MongoDB es adecuado para Hackathons, startups o cada vez que no sabes cómo consultarás los datos que insertaste. MongoDB no hace suposiciones sobre su esquema subyacente. Si bien MongoDB no tiene esquema y no es relacional, esto no significa que no exista ningún esquema. Simplemente significa que su esquema debe definirse en su aplicación (por ejemplo, usando Mongoose). Además de eso, MongoDB es ideal para crear prototipos o probar cosas. Su rendimiento no es tan bueno y no se puede comparar con Redis.

• Use Redis para acelerar su aplicación existente.

  Redis se puede integrar fácilmente como caché LRU . Es muy raro usar Redis como un sistema de base de datos independiente (algunas personas prefieren referirse a él como un almacén de "valor-clave"). Sitios web como Craigslist usan Redis junto a su base de datos primaria . Antirez (desarrollador de Redis) demostró usando Lamernews que de hecho es posible usar Redis como un sistema de base de datos independiente.

• Redis no hace suposiciones basadas en sus datos.

  Redis proporciona un montón de estructuras de datos útiles (por ejemplo, Conjuntos, hashes, listas), pero debe definir explícitamente cómo desea almacenar sus datos. En pocas palabras, Redis y MongoDB se pueden utilizar para lograr cosas similares. Redis es simplemente más rápido, pero no es adecuado para la creación de prototipos. Ese es un caso de uso en el que normalmente preferiría MongoDB. Además de eso, Redis es realmente flexible. Las estructuras de datos subyacentes que proporciona son los componentes básicos de los sistemas de bases de datos de alto rendimiento.

¿Cuándo usar Redis?

• Almacenamiento en caché

  El almacenamiento en caché con MongoDB simplemente no tiene mucho sentido. Sería muy lento

• Si tiene tiempo suficiente para pensar en su diseño de base de datos.

  No puede simplemente arrojar sus documentos a Redis. Debe pensar en la forma en que desea almacenar y organizar sus datos. Un ejemplo son los hashes en Redis. Son bastante diferentes de los objetos anidados "tradicionales", lo que significa que tendrá que repensar la forma en que almacena los documentos anidados. Una solución sería almacenar una referencia dentro del hash a otro hash (algo así como la clave: [id del segundo hash] ). Otra idea sería almacenarlo como JSON, lo que parece contrario a la intuición para la mayoría de las personas con un fondo * SQL.

• Si necesitas un rendimiento realmente alto.

  Vencer el rendimiento que ofrece Redis es casi imposible. Imagine que su base de datos es tan rápida como su caché. Eso es lo que se siente al usar Redis como una base de datos real .

• Si no se preocupan de que gran parte del cambio de escala.

  Escalar Redis no es tan difícil como solía ser. Por ejemplo, podría usar un tipo de servidor proxy para distribuir los datos entre múltiples instancias de Redis. La replicación maestro-esclavo no es que complicado, pero la distribución de claves entre múltiples necesidades Redis-casos para ser hecho en el lugar de aplicación (por ejemplo, utilizando una función hash, Modulo etc.). Escalar MongoDB en comparación es mucho más simple.

Cuando usar MongoDB

• Prototipos, Startups, Hackathons

  MongoDB es perfectamente adecuado para la creación rápida de prototipos. Sin embargo, el rendimiento no es tan bueno. También tenga en cuenta que lo más probable es que tenga que definir algún tipo de esquema en su aplicación.

• Cuando necesite cambiar su esquema rápidamente.

  ¡Porque no hay esquema! La alteración de tablas en DBMS relacionales tradicionales es dolorosamente costosa y lenta. MongoDB resuelve este problema al no hacer muchas suposiciones sobre sus datos subyacentes. Sin embargo, intenta optimizar lo más posible sin requerir que defina un esquema.

TL; DR : use Redis si el rendimiento es importante y está dispuesto a pasar tiempo optimizando y organizando sus datos. - Use MongoDB si necesita construir un prototipo sin preocuparse demasiado por su base de datos.

Otras lecturas:

• Aspectos interesantes a tener en cuenta al usar Redis como almacén de datos primario

Redis Digamos que has escrito un sitio en php; por alguna razón, se vuelve popular y se adelanta a su tiempo o tiene pornografía. Te das cuenta de que este php es tan lento, "voy a perder a mis fans porque simplemente no esperarán 10 segundos por una página". Te das cuenta repentinamente de que una página web tiene una URL constante (nunca cambia, whoa), una clave principal si lo deseas, y luego recuerdas que la memoria es rápida mientras el disco es lento y php es aún más lento. :( Luego, crea un mecanismo de almacenamiento utilizando la memoria y esta URL que llama una "clave", mientras que el contenido de la página web decide llamar al "valor". Eso es todo lo que tiene: clave y contenido. Lo llama "caché de memes". Te gusta Richard Dawkins porque es increíble. Guardas tu html como las ardillas guardan sus nueces. No necesitas reescribir tu código php basura. Usted es feliz. Entonces ves que otros lo han hecho, pero eliges Redis porque el otro tiene imágenes confusas de gatos, algunos con colmillos.

Mongo Has escrito un sitio. Diablos, has escrito muchos y en cualquier idioma. Te das cuenta de que gran parte de tu tiempo lo pasas escribiendo esas apestosas cláusulas SQL. No eres un dba, pero ahí estás, escribiendo estúpidas declaraciones SQL ... no solo una, sino volviendo loco en todas partes. "selecciona esto, selecciona eso". Pero en particular recuerdas la irritante cláusula WHERE. Donde el apellido es igual a "thornton" y la película es igual a "bad santa". Urgh Usted piensa, "¿por qué esos dbas simplemente no hacen su trabajo y me dan algunos procedimientos almacenados?" Luego, olvida algunos campos menores como el segundo nombre y luego tiene que abandonar la tabla, exportar todos los 10G de datos grandes y crear otro con este nuevo campo e importar los datos, y eso ocurre 10 veces durante los próximos 14 días a medida que avanza sigue recordando basura como saludo, título, además de agregar una clave foránea con direcciones. Luego calcula que el apellido debe ser el apellido. Casi un cambio por día. Entonces dices maldita sea. Tengo que subir y escribir un sitio web / sistema, no importa este modelo de datos bs. Entonces googleas, "Odio escribir SQL, por favor no SQL, haz que se detenga", pero aparece 'nosql' y luego lees algunas cosas y dice que solo voltea datos sin ningún esquema. Recuerdas el fiasco de la semana pasada que dejó caer más mesas y sonrió. Luego eliges mongo porque algunos grandes como 'airbud' lo usa el sitio de alquiler de apt. Dulce. No más cambios en el modelo de datos porque tiene un modelo que sigue cambiando.

Quizás este recurso sea útil para ayudar a decidir entre ambos. También analiza varias otras bases de datos NoSQL, y ofrece una breve lista de características, junto con una explicación de "para qué lo usaría" para cada una de ellas.

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Pregunta difícil de responder: como con la mayoría de las soluciones tecnológicas, realmente depende de su situación y, dado que no ha descrito el problema que está tratando de resolver, ¿cómo puede alguien proponer una solución?

Debe probarlos a ambos para ver cuál de ellos satisfizo sus necesidades.

Dicho esto, MongoDB no requiere ningún hardware costoso. Como cualquier otra solución de base de datos, funcionará mejor con más CPU y memoria, pero ciertamente no es un requisito, especialmente para fines de desarrollo temprano.

Redis es un almacén de datos en memoria , que puede conservar su estado en el disco (para permitir la recuperación después del reinicio). Sin embargo, ser un almacén de datos en memoria significa que el tamaño del almacén de datos (en un solo nodo) no puede exceder el espacio de memoria total en el sistema (RAM física + espacio de intercambio). En realidad, será mucho menos que esto, ya que Redis está compartiendo ese espacio con muchos otros procesos en el sistema, y ​​si agota el espacio de memoria del sistema, es probable que el sistema operativo lo elimine.

Mongo es un almacén de datos basado en disco , que es más eficiente cuando su conjunto de trabajo se ajusta dentro de la RAM física (como todo el software). El hecho de ser datos basados ​​en disco significa que no hay límites intrínsecos en el tamaño de una base de datos Mongo, sin embargo, las opciones de configuración, el espacio disponible en el disco y otras preocupaciones pueden significar que los tamaños de bases de datos por encima de cierto límite pueden volverse poco prácticos o ineficientes.

Tanto Redis como Mongo pueden agruparse para obtener alta disponibilidad, respaldo y para aumentar el tamaño general del almacén de datos.

Todas las respuestas (en el momento de escribir este artículo) asumen que cada una de Redis, MongoDB y quizás una base de datos relacional basada en SQL son esencialmente la misma herramienta: "almacenar datos". No consideran los modelos de datos en absoluto.

MongoDB: datos complejos

MongoDB es una tienda de documentos. Para comparar con una base de datos relacional basada en SQL: las bases de datos relacionales se simplifican a archivos CSV indexados, cada archivo es una tabla; Los almacenes de documentos se simplifican a archivos JSON indexados, cada archivo es un documento, con múltiples archivos agrupados.

Los archivos JSON tienen una estructura similar a los archivos XML y YAML, y a los diccionarios como en Python, así que piense en sus datos en ese tipo de jerarquía. Al indexar, la estructura es la clave: un documento contiene claves con nombre, que contienen documentos adicionales, matrices o valores escalares. Considere el siguiente documento.

{
  _id:  0x194f38dc491a,
  Name:  "John Smith",
  PhoneNumber:
    Home: "555 999-1234",
    Work: "555 999-9876",
    Mobile: "555 634-5789"
  Accounts:
    - "379-1111"
    - "379-2574"
    - "414-6731"
}

El documento anterior tiene una clave PhoneNumber.Mobile, que tiene valor 555 634-5789. Puede buscar en una colección de documentos donde la clave PhoneNumber.Mobile, tiene algún valor; Están indexados.

También tiene una variedad de los Accountscuales contienen múltiples índices. Es posible consultar un documento que Accountscontenga exactamente algún subconjunto de valores, todos algunos subconjuntos de valores o cualquiera de algunos subconjuntos de valores. Eso significa que puede buscar Accounts = ["379-1111", "379-2574"]y no encontrar lo anterior; puede buscar Accounts includes ["379-1111"]y encontrar el documento anterior; y puede buscar Accounts includes any of ["974-3785","414-6731"]y encontrar lo anterior y cualquier documento que incluya la cuenta "974-3785", si corresponde.

Los documentos son tan profundos como quieras. PhoneNumber.Mobilepodría contener una matriz o incluso un subdocumento ( PhoneNumber.Mobile.Worky PhoneNumber.Mobile.Personal). Si sus datos están altamente estructurados, los documentos son un gran paso adelante de las bases de datos relacionales.

Si sus datos son principalmente planos, relacionales y rígidamente estructurados, es mejor que tenga una base de datos relacional. Una vez más, la gran señal es si sus modelos de datos son mejores para una colección de archivos CSV interrelacionados o una colección de archivos XML / JSON / YAML.

Para la mayoría de los proyectos, tendrá que comprometerse, aceptando una solución menor en algunas áreas pequeñas donde SQL o Document Stores no encajan; Para algunos proyectos grandes y complejos que almacenan una amplia variedad de datos (muchas columnas; las filas son irrelevantes), tendrá sentido almacenar algunos datos en un modelo y otros datos en otro modelo. Facebook usa SQL y una base de datos gráfica (donde los datos se colocan en nodos y los nodos se conectan a otros nodos); Craigslist solía usar MySQL y MongoDB, pero había estado pensando en mudarse por completo a MongoDB. Estos son lugares donde el alcance y la relación de los datos se enfrentan a desventajas significativas si se colocan bajo un modelo.

Redis: valor-clave

Redis es, básicamente, una tienda de valores clave. Redis le permite darle una clave y buscar un valor único. Redis mismo puede almacenar cadenas, listas, hashes y algunas otras cosas; sin embargo, solo busca por nombre.

La invalidación de caché es uno de los problemas más difíciles de la informática; el otro es nombrar cosas. Eso significa que usará Redis cuando desee evitar cientos de búsquedas excesivas en un back-end, pero tendrá que averiguar cuándo necesita una nueva búsqueda.

El caso más obvio de invalidación es la actualización en escritura: si lee user:Simon:lingots = NOTFOUND, puede SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simonalmacenar el resultado 100, como SET user:Simon:lingots = 100. Entonces, cuando usted define el Simon 5 lingotes, que lee user:Simon:lingots = 100, SET user:Simon:lingots = 105y UPDATE Store s INNER JOIN UserProfile u ON s.UserID = u.UserID SET s.Lingots = 105 WHERE u.Username = Simon. Ahora tiene 105 en su base de datos y en Redis, y puede obtener user:Simon:lingotssin consultar la base de datos.

El segundo caso es actualizar la información dependiente. Supongamos que genera fragmentos de una página y almacena en caché su salida. El encabezado muestra la experiencia, el nivel y la cantidad de dinero del jugador; la página de Perfil del jugador tiene un bloque que muestra sus estadísticas; Etcétera. El jugador gana algo de experiencia. Bueno, ahora usted tiene varias templates:Header:Simon, templates:StatsBox:Simon, templates:GrowthGraph:Simon, y así sucesivamente campos donde se ha almacenado en caché la salida de una base de datos de media docena de consultas se ejecutan a través de un motor de plantillas. Normalmente, cuando muestra estas páginas, dice:

$t = GetStringFromRedis("templates:StatsBox:" + $playerName);
if ($t == null) {
  $t = BuildTemplate("StatsBox.tmpl",
                     GetStatsFromDatabase($playerName));
  SetStringInRedis("Templates:StatsBox:" + $playerName, $t);
}
print $t;

Debido a que acaba de actualizar los resultados de GetStatsFromDatabase("Simon"), debe abandonar templates:*:Simonsu caché de valores clave. Cuando intente representar cualquiera de estas plantillas, su aplicación eliminará los datos de su base de datos (PostgreSQL, MongoDB) y los insertará en su plantilla; luego almacenará el resultado en Redis y, con suerte, no se molestará en hacer consultas a la base de datos y generar plantillas la próxima vez que muestre ese bloque de salida.

Redis también le permite hacer colas de mensajes de suscripción de editor y demás. Ese es otro tema completamente. El punto aquí es que Redis es un caché de valores clave, que difiere de una base de datos relacional o un almacén de documentos.

Conclusión

Elija sus herramientas según sus necesidades. La mayor necesidad es generalmente el modelo de datos, ya que eso determina cuán complejo y propenso a errores es su código. Las aplicaciones especializadas se basarán en el rendimiento, lugares donde puede escribir todo en una mezcla de C y ensamblaje; la mayoría de las aplicaciones solo manejarán el caso generalizado y usarán un sistema de almacenamiento en caché como Redis o Memcached, que es mucho más rápido que una base de datos SQL de alto rendimiento o un almacén de documentos.

Y no debe usar ninguno si tiene mucha RAM. Redis y MongoDB llegan al precio de una herramienta de uso general. Esto introduce muchos gastos generales.

Se decía que Redis es 10 veces más rápido que Mongo. Puede que ya no sea así de cierto. MongoDB (si no recuerdo mal) afirmó que venció a Memcache para almacenar y almacenar en caché los documentos siempre que las configuraciones de memoria sean las mismas.

De todos modos. Redis bien, MongoDB es bueno. Si le interesan las subestructuras y necesita agregación, elija MongoDB. Si el almacenamiento de claves y valores es su principal preocupación, se trata de Redis. (o cualquier otro almacén de valores clave).

Redis y MongoDB son bases de datos no relacionales pero son de diferentes categorías.

Redis es una base de datos clave / valor, y está utilizando el almacenamiento en memoria que lo hace súper rápido. Es un buen candidato para el almacenamiento en caché de cosas y el almacenamiento temporal de datos (en memoria) y, dado que la mayoría de las plataformas en la nube (como Azure, AWS) lo admiten, su uso de memoria es escalable, pero si lo va a usar en sus máquinas con recursos limitados, considere su uso de memoria.

MongoDB, por otro lado, es una base de datos de documentos. Es una buena opción para guardar textos grandes, imágenes, videos, etc. y casi cualquier cosa que haga con bases de datos, excepto transacciones. Por ejemplo, si desea desarrollar un blog o una red social, MongoDB es una opción adecuada. Es escalable con una estrategia de escalamiento horizontal. Utiliza el disco como medio de almacenamiento, por lo que los datos se conservarán.

Si su proyecto presupuestado le permite tener suficiente memoria RAM en su entorno, la respuesta es Redis. Especialmente teniendo en cuenta el nuevo Redis 3.2 con funcionalidad de clúster.