español engine cache architecture mongodb nosql redis

architecture - engine - ¿Cuándo a Redis? ¿Cuándo a MongoDB?



redis vs mongodb español (10)

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

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

    MongoDB es adecuado para hackathons, startups o cada vez que no sepa cómo consultar los datos que inserta. 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, usar Mongoose). Además de eso, MongoDB es ideal para hacer prototipos o probar cosas. Su rendimiento no es tan bueno y no se puede comparar con Redis.

  • Utilice Redis para acelerar su aplicación existente.

    Redis se puede integrar fácilmente como un caché LRU . Es muy infrecuente utilizar 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 utilizan Redis junto a su base de datos principal . Antirez (desarrollador de Redis) demostró usando Lamernews que es posible utilizar 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 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 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 DB de alto rendimiento.

¿Cuándo usar Redis?

  • Almacenamiento en caché

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

  • Si tienes tiempo suficiente para pensar en el diseño de tu base de datos.

    No puedes simplemente meter tus documentos en Redis. Debe pensar en la forma en que desea almacenar y organizar sus datos. Un ejemplo son los hashes en redis. Son muy 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, que parece contrario a la intuición para la mayoría de las personas con un fondo * SQL.

  • Si necesitas un rendimiento realmente alto.

    Superar el rendimiento que proporciona Redis es casi imposible. Imagina que tu base de datos sea tan rápida como tu caché. Eso es lo que se siente al usar Redis como una base de datos real .

  • Si no te importa mucho sobre la escala.

    El escalado de 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 las claves entre varias instancias de Redis debe realizarse en el sitio de la aplicación (por ejemplo, mediante una función hash, Módulo, etc.). La escala de MongoDB en comparación es mucho más simple.

Cuándo 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 necesites cambiar tu esquema rápidamente.

    ¡Porque no hay esquema! Alterar las tablas en el DBMS relacional tradicional es dolorosamente caro y lento. MongoDB resuelve este problema al no hacer muchas suposiciones sobre sus datos subyacentes. Sin embargo, intenta optimizar en la medida de lo posible sin requerir que definas un esquema.

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

Otras lecturas:

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 el API es muy fácil de usar y estoy muy contento con él.

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 el desarrollo tanto como pueda, pero necesita una máquina costosa.

Entonces, ¿qué piensas 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 necesita realizar muchas consultas , eso significa que los desarrolladores utilizarán Redis en mayor medida, ya que su información podría almacenarse en una variedad de estructuras de datos especializadas, personalizadas para cada tipo de objeto por 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 rapidez de la respuesta a esas consultas es la recompensa por el trabajo adicional de tratar 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 los desarrolladores con experiencia tradicional de 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 datos más esquematizados, MongoDB es mejor. [Nota: tanto MongoDB como Redis son técnicamente esquemáticos]

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

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

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

Necesitas probarlos para ver cuál de ellos satisfizo tus 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 propósitos de desarrollo temprano.

Redis es un almacén de datos en memoria , que puede persistir en estado en disco (para habilitar 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 la memoria del sistema, probablemente será eliminado por el sistema operativo.

Mongo es un almacén de datos basado en disco , que es más eficiente cuando funciona, 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 el tamaño de las bases de datos sobre un cierto límite puede volverse impráctico o ineficiente.

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

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

Redis es una base de datos de Clave / Valor, y usa almacenamiento en memoria que lo hace súper rá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 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 estrategia de ampliación. Utiliza el disco como medio de almacenamiento, por lo que los datos se conservarán.

Redis. Digamos que has escrito un sitio en php; por la razón que sea, se vuelve popular y está adelantado a su tiempo o tiene contenido porno. Te das cuenta de que este php es muy lento, "voy a perder a mis fans porque simplemente no esperarán 10 segundos por una página". Se da cuenta repentinamente de que una página web tiene una url constante (nunca cambia, whoa), una clave principal si así lo desea, y luego recuerda que la memoria es rápida, mientras que el disco es lento y el php es incluso más lento. :( Luego, crea un mecanismo de almacenamiento utilizando la memoria y esta URL a la que llama "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. Cacheas tu html como las ardillas cachean sus nueces. No necesitas volver a escribir tu código de PHP de mierda. Estás feliz. Luego ves que otros lo han hecho, pero eliges Redis porque otra tiene imágenes confusas de gatos, algunas con colmillos.

Mongo Has escrito un sitio. Diablos has escrito muchos, y en cualquier idioma. Te das cuenta de que pasas gran parte de tu tiempo escribiendo esas cláusulas de SQL apestosas. No eres un dba, sin embargo, ahí estás, escribiendo declaraciones de SQL estupidas ... no solo una, sino alucinando por 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 "mala santa". Urgh. Piensas: "¿por qué esas dbas simplemente no hacen su trabajo y me dan algunos procedimientos almacenados?" Luego olvida un campo secundario como middlename y luego debe abandonar la tabla, exportar todos los 10G de big data 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 el saludo, el título y el agregado de una clave externa con direcciones. Entonces piensas que el apellido debería ser apellido. Casi un cambio al día. Entonces dices cariño. Tengo que seguir y escribir un sitio web / sistema, no importa este modelo de datos bs. Entonces, busca en Google: "Odio escribir SQL, por favor, no SQL, haz que se detenga", pero aparece "nosql" y luego lees algunas cosas y dice que simplemente vuelca los datos sin ningún esquema. Recuerdas el fiasco de la semana pasada cayendo más mesas y sonriendo. Luego elige mongo porque algunos tipos grandes como ''airbud'' lo usa el sitio de alquiler apto. Dulce. No más cambios en el modelo de datos porque tienes un modelo que solo sigues cambiando.

Si su proyecto de presupuesto 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 cluster.

Todas las respuestas (en el momento de escribir este artículo) suponen que cada 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 un almacén de documentos. Para comparar con una base de datos relacional controlada por SQL: las bases de datos relacionales se simplifican a los archivos CSV indexados, cada archivo es una tabla; los almacenes de documentos se simplifican a los archivos JSON indexados, cada archivo es un documento, con varios 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, arreglos 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 un valor 555 634-5789 . Puede buscar en una colección de documentos donde la clave, PhoneNumber.Mobile , tenga algún valor; están indexados

También tiene una serie de Accounts que contienen múltiples índices. Es posible consultar un documento en el que Accounts contiene exactamente un subconjunto de valores, todos algunos de un subconjunto de valores, o cualquiera de algún subconjunto 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 van tan profundos como quieras. PhoneNumber.Mobile puede 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 avance desde las bases de datos relacionales.

Si sus datos son en su mayoría planos, relacionales y rígidamente estructurados, estará mejor con una base de datos relacional. Una vez más, el gran signo es si sus datos se adaptan mejor a 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 de trabajo menor en algunas áreas pequeñas donde no caben ni SQL ni Document Stores; 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 utiliza tanto SQL como 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 buscando mudarse completamente 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: Key-Value

Redis es, básicamente, una tienda de valor-clave. Redis le permite darle una clave y buscar un solo valor. Redis 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 quiera evitar cientos de búsquedas excesivas en un back-end, pero tendrá que descubrir cuándo necesita una nueva búsqueda.

El caso más obvio de invalidación es la actualización en escritura: si lees 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 resultado, 100 , como SET user:Simon:lingots = 100 . Luego, cuando 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 user:Simon:lingots sin consultar la base de datos.

El segundo caso es actualizar la información dependiente. Digamos que usted 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 tiene varias templates:Header:Simon , templates:StatsBox:Simon , templates:GrowthGraph:Simon , y otros campos donde ha almacenado en caché la salida de media docena de consultas de base de datos que se ejecutan a través de un motor de plantillas. Normalmente, cuando visualizas estas páginas, dices:

$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 eliminar las templates:*:Simon de su caché de valores clave. Cuando intente renderizar 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 de bases de datos y renderizar plantillas la próxima vez que muestre ese bloque de resultados.

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

Conclusión

Elige tus herramientas en función de tus necesidades. La mayor necesidad suele ser el modelo de datos, ya que eso determina qué tan complejo y propenso a errores sea su código. Las aplicaciones especializadas se basarán en el rendimiento, los lugares donde se escribe todo en una mezcla de C y Ensamblado; la mayoría de las aplicaciones solo manejarán el caso generalizado y utilizará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 debes usar ninguno si tienes mucha RAM. Redis y MongoDB llegan al precio de una herramienta de propósito general. Esto introduce una gran cantidad de gastos generales.

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

De todos modos. Redis bueno, MongoDB es bueno. Si le interesan las subestructuras y necesita agregación, vaya a 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).