2012-08-04 39 views
6

He estado leyendo en MongoDB. Estoy particularmente interesado en la capacidad de los marcos de agregación. Estoy buscando tomar múltiples conjuntos de datos que constan de al menos más de 10 millones de filas por mes y crear agregaciones de estos datos. Esto es datos de series de tiempo.MongoDB - Vista materializada/Agregación de estilo OLAP

Ejemplo. Al utilizar Oracle OLAP, puede cargar datos en el segundo/minuto y hacer que se acumulen en horas, días, semanas, meses, trimestres, años, etc. ... simplemente defina sus dimensiones e inicie desde allí. Esto funciona bastante bien

Hasta ahora he leído que MongoDB puede manejar lo anterior utilizando su funcionalidad de reducción de mapa. La funcionalidad de reducción de mapas se puede implementar para que actualice los resultados de forma incremental. Esto tiene sentido ya que estaría cargando datos nuevos, por ejemplo, semanalmente o mensualmente, y esperaría tener que procesar solo los datos nuevos que se están cargando.

También he leído que la reducción del mapa en MongoDB puede ser lenta. Para superar esto, la idea es usar un hardware básico barato y distribuir la carga entre múltiples máquinas.

Así que aquí están mis preguntas.

  1. ¿Qué tan bueno (o malo) hace MongoDB handle map reducir en términos de rendimiento? ¿Realmente necesita muchas máquinas para obtener un rendimiento aceptable?
  2. En términos de flujo de trabajo, ¿es relativamente fácil almacenar y combinar los resultados incrementales generados por la reducción de mapa?
  3. ¿Cuánta mejora de rendimiento ofrece el marco de agregación?
  4. El marco de agregación ofrece la capacidad de almacenar resultados de forma incremental de manera similar a la funcionalidad de asignación/reducción que ya existe.

¡Agradezco tus respuestas de antemano!

Respuesta

8

Qué tan bueno (o malo) hace MongoDB handle map reducir en términos de rendimiento? ¿Realmente necesita muchas máquinas para obtener un rendimiento aceptable?

MongoDB's Map/Reduce la implementación (a partir de 2.0.x) está limitado por su dependencia de la SpiderMonkey JavaScript engine de un solo hilo. Ha habido algunos experimentos con el v8 JavaScript engine y la simultaneidad mejorada y el rendimiento es un objetivo de diseño general.

La nueva Aggregation Framework está escrita en C++ y tiene una implementación más escalable que incluye un enfoque de "canalización". Cada tubería tiene actualmente un único subproceso, pero puede ejecutar diferentes interconexiones en paralelo. El marco de agregación actualmente no reemplazará todos los trabajos que se pueden hacer en Mapa/Reducir, pero simplifica muchos casos de uso común.

Una tercera opción es usar MongoDB para el almacenamiento en combinación con Hadoop a través del MongoDB Hadoop Connector. Actualmente, Hadoop tiene una implementación de mapa/reducción más escalable y puede acceder a las colecciones de MongoDB para la entrada y salida a través del conector de Hadoop.

En términos de flujo de trabajo, ¿es relativamente fácil almacenar y combinar los resultados incrementales generados por map reduce?

Mapa/Reducir tiene varias output options, incluyendo la fusión de la salida gradual en una colección de salida anterior o devolución de los resultados en línea (en la memoria).

¿Cuánta mejora de rendimiento ofrece el marco de agregación?

Esto realmente depende de la complejidad de su Mapa/Reducir. En general, el marco de agregación es más rápido (y en algunos casos, significativamente). Lo mejor es hacer una comparación para su (s) propio (s) caso (s) de uso.

MongoDB 2.2 aún no se ha lanzado oficialmente, pero el 2.2rc0 release candidate ha estado disponible desde mediados de julio.

El marco de agregación ofrece la capacidad de almacenar resultados de forma incremental de manera similar a la funcionalidad de asignación/reducción que ya existe.

El marco de agregación actualmente se limita a devolver resultados en línea, por lo que debe procesar/mostrar los resultados cuando se devuelven. El documento resultante también está restringido al tamaño máximo del documento en MongoDB (actualmente 16 MB).

Existe una propuesta de $out canalizar el comando (SERVER-3253) que probablemente se agregará en el futuro para más opciones de salida.

leer un poco más lejos que pueda ser de interés:

+2

Actualización: A partir de Mongo 2,4 el valor por defecto del motor V8 javscript es ahora (http://docs.mongodb.org/manual/release-notes /2.4/#javascript-engine-changed-to-v8) – del

Cuestiones relacionadas