Cuando a Redis? ¿Cuándo MongoDB?

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 geniales y quiero usar Redis en la implementación tanto como pueda, pero es difícil codificar. Quiero usar MongoDB en desarrollo tanto como pueda, pero necesita una máquina cara.

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

Me di cuenta de 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 los datos que has insertado. MongoDB no hace suposiciones en su esquema subyacente. Si bien MongoDB es esquemático y no relacional, esto no significa que no haya 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 un caché LRU . Es muy poco común usar Redis como un sistema de base de datos independiente (algunas personas prefieren referirse a él como una tienda de “valor clave”). Los sitios web como Craigslist usan Redis junto a su base de datos principal . Antirez (desarrollador de Redis) demostró utilizando 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 conjunto de estructuras de datos útiles (por ejemplo, Conjuntos, Hashes, Listas), pero tiene que definir explícitamente cómo desea almacenar sus datos. Para decirlo en pocas palabras, Redis y MongoDB pueden usarse para lograr cosas similares. Redis es simplemente más rápido, pero no 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 DB de alto rendimiento.

Cuándo usar Redis?

  • Almacenamiento en caché

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

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

    No puedes simplemente tirar tus documentos a Redis. Tienes que pensar en la forma en que deseas almacenar y organizar tus datos. Un ejemplo son los hashes en Redis. Son bastante diferentes de los objetos nesteds “tradicionales”, lo que significa que tendrá que replantearse la forma en que almacena los documentos nesteds. Una solución sería almacenar una referencia dentro del hash a otro hash (algo así como 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 * SQL-background.

  • Si necesitas un rendimiento realmente alto.

    Vencer el rendimiento que proporciona 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 te importa tanto la 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 varias instancias de Redis. La replicación maestro-esclavo no es tan complicada, pero la distribución de claves entre múltiples instancias de Redis debe realizarse en el sitio de la aplicación (por ejemplo, utilizando una función hash, módulo, etc.). Escalar MongoDB en comparación es mucho más simple.

Cuándo usar MongoDB

  • Creación de prototipos, Startups, Hackathons

    MongoDB es ideal para prototipos rápidos. 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! Alterar las tablas en DBMS tradicional relacional es dolorosamente costoso y lento. MongoDB resuelve este problema al no hacer muchas suposiciones sobre sus datos subyacentes. Sin embargo, trata de optimizar lo más posible sin necesidad de definir un esquema.

TL; DR : utilice Redis si el rendimiento es importante y está dispuesto a perder tiempo optimizando y organizando sus datos. – Usa MongoDB si necesitas construir un prototipo sin preocuparte demasiado por tu DB.

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 está adelantada a su tiempo o tiene pornografía. Te das cuenta de que este php es tan lento, “Voy a perder mis fans porque simplemente no esperarán 10 segundos para 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 que el disco es lento y php es incluso más lento. 🙁 Luego crea un mecanismo de almacenamiento usando la memoria y esta URL que llama “clave” mientras el contenido de la página web decide llamar al “valor”. Eso es todo lo que tiene: clave y contenido. Lo llama “meme cache”. Te gusta Richard Dawkins porque es increíble. Guardas en el caché tu html como las ardillas guardan sus nueces. No necesitas volver a escribir tu código php. Eres feliz. Luego ves que otros lo han hecho, pero eliges a Redis porque el otro tiene imágenes confusas de gatos, algunos con colmillos.

Mongo. Usted ha escrito un sitio. Diablos, has escrito muchos y en cualquier idioma. Se da cuenta de que gran parte de su tiempo lo dedica a escribir esas pésimas cláusulas SQL. No eres un dba, sin embargo, ahí estás, escribiendo estúpidas declaraciones SQL … no solo una, sino volviendo loca por todos lados. “selecciona esto, selecciona eso”. Pero, en particular, recuerdas la irritante cláusula WHERE. Donde apellido equivale a “thornton” y la película equivale a “mala santa”. Urgh. Usted piensa, “¿por qué esos dbas no hacen su trabajo y me dan algunos procedimientos almacenados?” Luego, olvida un campo menor como middlename y luego tiene que soltar la tabla, exportar todos los 10G de big data y crear otro con este nuevo campo, e importar los datos, y eso sucede 10 veces durante los próximos 14 días mientras usted sigue recordando basura como saludo, título, además de agregar una clave externa con direcciones. Entonces calcula que el apellido debe ser lastName. Casi un cambio por día. Entonces dices maldito. Tengo que entrar y escribir un sitio web / sistema, no importa este modelo de datos bs. Entonces google: “Odio escribir SQL, por favor, no SQL, haz que se detenga”, pero aparece “me gusta” y luego lees algunas cosas y dice que simplemente vuelca datos sin ningún esquema. Recuerdas el fiasco de la semana pasada dejando caer más mesas y sonreír. Entonces eliges mongo porque algunos tipos grandes como ‘airbud’ usan el sitio de alquiler de apt. Dulce. No hay más cambios en el modelo de datos porque tienes un modelo que simplemente sigues cambiando.

Tal vez 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 “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, como no ha descrito el problema que está tratando de resolver, ¿cómo puede alguien proponer una solución?

Debe probarlos para ver cuál de ellos satisface 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 (espacio físico de RAM + 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 mate.

Mongo es un almacén de datos basado en disco , que es más eficiente cuando está funcionando, se ajusta a la memoria RAM física (como todo el software). Ser un disco basado en datos significa que no existen límites intrínsecos al 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 que sobrepasan cierto límite pueden volverse poco prácticos o ineficaces.

Tanto Redis como Mongo se pueden agrupar para alta disponibilidad, copia de seguridad y para boost el tamaño total del almacén de datos.

Todas las respuestas (al momento de escribir esto) asumen que 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 impulsada por SQL: las bases de datos relacionales simplifican a los archivos CSV indexados, cada archivo es una tabla; las tiendas de documentos simplifican a los archivos JSON indexados, cada archivo es un documento, con múltiples archivos agrupados.

Los archivos JSON son similares en estructura 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. Considera 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 el valor 555 634-5789 . Puede buscar a través de una colección de documentos donde la clave, PhoneNumber.Mobile , tiene algún valor; están indexados

También tiene una matriz de Accounts que tienen múltiples índices. Es posible consultar un documento donde Accounts contiene exactamente un subconjunto de valores, todos los subconjuntos de valores o cualquiera de los 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 encuentra el documento anterior; y puede buscar Accounts includes any of ["974-3785","414-6731"] y encuentre lo anterior y cualquier documento incluye la cuenta “974-3785”, si corresponde.

Los documentos van tan profundo como quieras. PhoneNumber.Mobile podría contener una matriz, o incluso un sub-documento ( PhoneNumber.Mobile.Work y PhoneNumber.Mobile.Personal ). Si sus datos están altamente estructurados, los documentos son un gran paso adelante desde las bases de datos relacionales.

Si sus datos son en su mayoría planas, relacionales y rígidamente estructurados, estará mejor con una base de datos relacional. Nuevamente, 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, deberá comprometerse, aceptando una pequeña solución 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), tiene sentido almacenar algunos datos en un modelo y otros datos en otro modelo. Facebook usa tanto SQL como una base de datos de gráficos (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 buscando pasar completamente a MongoDB. Estos son lugares donde el lapso y la relación de los datos se enfrenta a desventajas significativas si se coloca bajo un modelo.

Redis: clave-valor

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

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

El caso más obvio de invalidación es la actualización al escribir: si lees al user:Simon:lingots = NOTFOUND , puedes SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simon y almacenar el resultado, 100 , como SET user:Simon:lingots = 100 . Luego, cuando le otorga Simon 5 lingotes, lee el user:Simon:lingots = 100 , SET user:Simon:lingots = 105 , y 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 el user:Simon:lingots sin consultar la base de datos.

El segundo caso es actualizar la información dependiente. Digamos que generas trozos de una página y almacenan en caché su salida. El encabezado muestra la experiencia, el nivel y la cantidad de dinero del jugador; la página Perfil del jugador tiene un bloque que muestra sus estadísticas; Etcétera. El jugador gana algo de experiencia. Bueno, ahora tiene varias templates:Header:Simon , templates:StatsBox:Simon , templates:GrowthGraph:Simon , y otros campos en los que templates:GrowthGraph:Simon caché el resultado de una media docena de consultas de bases de datos que se ejecutan a través de un motor de plantillas. Normalmente, cuando visualiza 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") , tiene que soltar templates:*:Simon fuera de la memoria caché clave-valor. Cuando intenta renderizar cualquiera de estas plantillas, su aplicación eliminará la obtención de 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 de base de datos y plantillas de renderizado 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 cosas por el estilo. Ese es otro tema por completo. El punto aquí es que Redis es un caché de clave-valor, 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 suele ser el modelo de datos, ya que eso determina cuán complejo y propenso a errores es su código. Las aplicaciones especializadas se apoyarán en el rendimiento, lugares donde se escribe todo en una mezcla de C y ensamblaje; la mayoría de las aplicaciones solo manejarán el caso generalizado y utilizarán un sistema de caché como Redis o Memcached, que es mucho más rápido que una base de datos SQL de alto rendimiento o una tienda de documentos.

Y no deberías usar ninguno si tienes mucha RAM. Redis y MongoDB llegan al precio de una herramienta de propósito general. Esto introduce mucha sobrecarga.

Hubo el dicho de que Redis es 10 veces más rápido que Mongo. Eso podría no ser tan cierto nunca más. MongoDB (si no recuerdo mal) afirmó vencer a Memcache para almacenar y almacenar en caché 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, vaya a MongoDB. Si almacenar claves y valores es su principal preocupación, todo 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, lo que lo hace superrápido. Es un buen candidato para el almacenamiento en caché y el almacenamiento temporal de datos (en memoria) y como la mayoría de las plataformas en la nube (como Azure, AWS) lo admiten, su uso de memoria es escalable. Pero si vas a usarlo en tus 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 las bases de datos, excepto las 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 se movió 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.