mongodb - tipos - nosql pdf
MongoDB vs. Redis vs. Cassandra para una solución de almacenamiento de fila temporal de escritura rápida (9)
Estoy construyendo un sistema que rastrea y verifica impresiones de anuncios y clics. Esto significa que hay una gran cantidad de comandos de inserción (aproximadamente 90 / segundo promedio, máximo en 250) y algunas operaciones de lectura, pero el foco está en el rendimiento y lo hace increíblemente rápido.
El sistema se encuentra actualmente en MongoDB, pero me han presentado a Cassandra y Redis desde entonces. ¿Sería una buena idea recurrir a una de estas dos soluciones, en lugar de permanecer en MongoDB? ¿Por qué o por qué no?
Gracias
Acabo de encontrar esto: http://blog.axant.it/archives/236
Citando la parte más interesante:
Este segundo gráfico es sobre Redis RPUSH vs Mongo $ PUSH vs Mongo insert, y creo que este gráfico es realmente interesante. Hasta 5.000 entradas mongodb $ push es más rápido incluso cuando se compara con Redis RPUSH, luego se vuelve increíblemente lento, probablemente el tipo de matriz mongodb tiene un tiempo de inserción lineal y, por lo tanto, se vuelve cada vez más lento. mongodb puede obtener un poco de rendimiento al exponer un tipo de lista de inserción de tiempo constante, pero incluso con el tipo de matriz de tiempo lineal (que puede garantizar la búsqueda de tiempo constante) tiene sus aplicaciones para pequeños conjuntos de datos.
Supongo que todo depende al menos en el tipo de datos y el volumen. El mejor consejo probablemente sería comparar su conjunto de datos típico y verse a sí mismo.
Actualmente trabajo para una red publicitaria muy grande y escribimos en archivos planos :)
Personalmente soy fanático de Mongo, pero francamente, Redis y Cassandra probablemente no se desempeñarán mejor o peor. Quiero decir, todo lo que estás haciendo es tirar cosas a la memoria y luego tirarlas al disco en segundo plano (tanto Mongo como Redis hacen esto).
Si está buscando una velocidad ultra rápida, la otra opción es mantener varias impresiones en la memoria local y luego enjuagarlas cada minuto más o menos. Por supuesto, esto es básicamente lo que Mongo y Redis hacen por ti. No es una razón convincente real para moverse.
De acuerdo con las bases de datos Benchmarking Top NoSQL ( descarga aquí ), recomiendo Cassandra.
El problema con las inserciones en las bases de datos es que generalmente requieren escribir en un bloque al azar en el disco para cada inserción. Lo que desea es algo que solo se escribe en el disco cada 10 insertos, idealmente para bloques secuenciales.
Los archivos planos son buenos. Las estadísticas de resumen (por ejemplo, visitas totales por página) se pueden obtener a partir de archivos planos de una manera escalable usando algoritmos tipo merge-sorty map-reducy. No es demasiado difícil de hacer tu propio.
SQLite ahora es compatible con Write Ahead Logging, que también puede proporcionar un rendimiento adecuado.
Las tres soluciones (cuatro si cuenta archivos planos) le proporcionarán grabaciones extremadamente rápidas. Las soluciones no relacionales (nosql) le darán tolerancia a fallas sintonizable también para propósitos de recuperación ante desastres.
En términos de escala, nuestro entorno de prueba, con solo tres nodos MongoDB, puede manejar 2-3k transacciones mixtas por segundo. En 8 nodos, podemos manejar transacciones mixtas de 12k-15k por segundo. Cassandra puede escalar aún más. 250 lecturas es (o debería ser) sin problema.
La pregunta más importante es, ¿qué quieres hacer con esta información? Informes operacionales? ¿Análisis de series temporales? Análisis de patrones ad-hoc? informes en tiempo real?
MongoDB es una buena opción si desea la capacidad de realizar análisis ad-hoc basados en múltiples atributos dentro de una colección. Puedes poner hasta 40 índices en una colección, aunque los índices se almacenarán en la memoria, así que ten cuidado con el tamaño. Pero el resultado es una solución analítica flexible.
Cassandra es una tienda de valores clave. Usted define una columna estática o un conjunto de columnas que actuarán como su índice principal directamente al frente. Todas las consultas ejecutadas contra Cassandra deben ajustarse a este índice. Puedes ponerle un secundario, pero eso es todo lo que puede pasar. Por supuesto, puede usar MapReduce para escanear la tienda por atribución sin clave, pero será solo eso: un escaneo en serie a través de la tienda. Cassandra tampoco tiene la noción de operaciones "similares" o expresiones regulares en los nodos del servidor. Si desea buscar todos los clientes donde el nombre comienza con "Alex", deberá escanear toda la colección, sacar el primer nombre de cada entrada y ejecutarlo a través de una expresión regular del lado del cliente.
No estoy lo suficientemente familiarizado con Redis para hablar inteligentemente al respecto. Lo siento.
Si está evaluando plataformas no relacionales, es posible que también desee considerar CouchDB y Riak.
Espero que esto ayude.
Para una solución de cosecha como esta, recomendaría un enfoque de etapas múltiples. Redis es bueno en la comunicación en tiempo real . Redis está diseñado como un almacén de claves / valores en memoria y hereda algunos beneficios muy buenos de ser una base de datos de memoria: O (1) enumera las operaciones. Mientras haya memoria RAM para usar en un servidor, Redis no reducirá la velocidad hasta el final de la lista, lo que es bueno cuando necesita insertar elementos a una velocidad tan extrema. Desafortunadamente, Redis no puede operar con conjuntos de datos más grandes que la cantidad de RAM que tiene (solo escribe en el disco, la lectura sirve para reiniciar el servidor o en caso de un bloqueo del sistema) y usted y su aplicación deben realizar el escalado . (Una forma común es distribuir claves a través de numerosos servidores, que es implementada por algunos controladores de Redis, especialmente los de Ruby on Rails). Redis también tiene soporte para el messenging simple de publicación / suscripción, que también puede ser útil en ocasiones.
En este escenario, Redis es "etapa uno". Para cada tipo específico de evento, usted crea una lista en Redis con un nombre único; por ejemplo, tenemos "página vista" y "enlace hecho clic". Para simplificar, queremos asegurarnos de que los datos en cada lista sean de la misma estructura; El enlace en el que se hace clic puede tener un token de usuario, nombre de enlace y URL, mientras que la página vista solo puede tener token de usuario y URL. Su primera preocupación es simplemente obtener el hecho de que sucedió y se empuja cualquier información absolutamente necesaria que necesita.
A continuación tenemos algunos trabajadores de procesamiento simple que toman esta información frenéticamente insertada de las manos de Redis, pidiéndole que tome un artículo del final de la lista y se lo entregue. El trabajador puede realizar los ajustes / deduplicación / búsquedas de ID necesarios para archivar adecuadamente los datos y entregarlos a un sitio de almacenamiento más permanente. Despida a tantos de estos trabajadores como sea necesario para mantener la carga de memoria de Redis soportable. Puede escribir a los trabajadores en cualquier cosa que desee (Node.js, C #, Java, ...) siempre que tenga un controlador Redis (la mayoría de los lenguajes web ahora) y uno para su almacenamiento deseado (SQL, Mongo, etc.). )
MongoDB es bueno en el almacenamiento de documentos . A diferencia de Redis, es capaz de manejar bases de datos más grandes que RAM y admite fragmentación / replicación por sí mismo. Una ventaja de MongoDB sobre las opciones basadas en SQL es que no tiene que tener un esquema predeterminado, puede cambiar la forma en que los datos se almacenan como lo desee en cualquier momento.
Sin embargo, sugiero a Redis o Mongo para la fase "paso uno" de almacenar datos para procesarlos y usar una configuración tradicional de SQL (Postgres o MSSQL, tal vez) para almacenar datos procesados. Seguir el comportamiento del cliente me suena a datos relacionales, ya que es posible que desee ir a "Mostrarme a todos los que ven esta página" o "¿Cuántas páginas vio esta persona en este día?" O "¿Qué día tuvo más espectadores en total? ". Puede haber uniones o consultas aún más complejas para fines analíticos que se te ocurran, y las soluciones SQL maduras pueden hacer mucho de este filtrado para ti; NoSQL (específicamente Mongo o Redis) no puede hacer uniones o consultas complejas entre varios conjuntos de datos.
Puedo obtener alrededor de 30k inserciones / seg con MongoDB en un Dell simple de $ 350. Si solo necesitas alrededor de 2k inserciones / seg, me quedaría con MongoDB y haré una escala para la escalabilidad. Tal vez también busque hacer algo con Node.js o algo similar para hacer que las cosas sean más asincrónicas.
Si tienes la opción (y necesitas alejarte de las planas) me gustaría ir con Redis. Es sorprendentemente rápido, manejará cómodamente la carga de la que está hablando, pero lo más importante es que no tendrá que administrar el código de enjuague / IO. Entiendo que es bastante sencillo pero menos código para administrar es mejor que más.
También obtendrá opciones de escala horizontal con Redis que puede que no obtenga con el almacenamiento en caché basado en archivos.
Tengo experiencia práctica con mongodb, couchdb y cassandra. Convertí una gran cantidad de archivos a la cadena base64 e inserté esta cadena en nosql.
mongodb es el más rápido. Casandra es la más lenta. couchdb también es lento.
Creo que mysql sería mucho más rápido que todos ellos, pero aún no probé mysql para mi caso de prueba.