Cargando y analizando cantidades masivas de datos

Question

Por lo tanto, para algunos trabajos de investigación, necesito analizar una tonelada de datos de movimientos en bruto (actualmente casi un registro de datos, y en crecimiento) y escupir información cuantitativa y trazados.

Escribí la mayoría utilizando Groovy (con JFreeChart para crear gráficos) y cuando el rendimiento se convirtió en un problema, reescribí las partes principales en Java.

El problema es que el análisis y el trazado dura aproximadamente un minuto, mientras que la carga de todos los datos lleva unos 5-10 minutos. Como se puede imaginar, esto se vuelve realmente molesto cuando quiero hacer pequeños cambios en los gráficos y ver la salida.

Tengo un par de ideas sobre la fijación del mismo:

1. cargar todos los datos en una base de datos SQLite.
   Beneficios: Será rápido. Podré ejecutar SQL para obtener datos agregados si es necesario.

   Contras: Tengo que escribir todo ese código. Además, para algunas de las parcelas, necesito acceso a cada punto de datos, por lo que cargar algunos cientos de miles de archivos, algunas partes pueden ser lentas.

2. Java RMI para devolver el objeto. Todos los datos se cargan en un objeto raíz, que, cuando se serializa, es de aproximadamente 200 megas. No estoy seguro de cuánto tiempo llevaría transferir un objeto de 200 megas a través de RMI. (mismo cliente).

   Tendría que ejecutar el servidor y cargar todos los datos, pero eso no es gran cosa.

   Major Pro: esto debe tomar la menor cantidad de tiempo para escribir

3. ejecutar un servidor que carga los datos y ejecuta un guión maravilloso de mando dentro de la máquina virtual servidor. En general, esto parece la mejor idea (para el tiempo de implementación vs rendimiento, así como otros beneficios a largo plazo)

Lo que me gustaría saber es que otras personas abordado este problema?

Post-análisis (29/03/2011): Un par de meses después de escribir esta pregunta, terminé teniendo que aprender R para ejecutar algunas estadísticas. Usando R era mucho, mucho más fácil y más rápido para el análisis de datos y la agregación de lo que estaba haciendo.

Eventualmente, terminé usando Java para ejecutar la agregación preliminar, y luego ejecuté todo lo demás en R. R también era mucho más fácil hacer gráficos hermosos que usar JFreeChart.

Answer 1

bases de datos son muy escalable, si va a tener grandes cantidades de datos. En MS SQL actualmente agrupamos/sumamos/filtramos unos 30 GB de datos en 4 minutos (alrededor de 17 millones de registros, creo).

Si los datos no van a crecer mucho, entonces probaría el enfoque n. ° 2. Puede crear una aplicación de prueba simple que cree un objeto de 200-400mb con datos aleatorios y probar el rendimiento de la transferencia antes de decidir si desea realizar esa ruta.

Answer 2

Si sus datos tienen propiedades relacionales, no hay nada más natural que almacenarlos en alguna base de datos SQL. Allí puede resolver su mayor problema: rendimiento, que cuesta "solo" escribir su código SQL apropiado.

parece muy claro para mí.

Answer 3

Me gustaría analizar el análisis con R. Es un lenguaje estadístico con capacidades de gráficos. Podría anticiparte, especialmente si ese es el tipo de análisis que intentas hacer. ¿Por qué escribir todo ese código?

Answer 4

Ah, sí: grandes estructuras de datos en Java. Buena suerte con eso, sobreviviendo "death by garbage collection" y todo. Lo que java parece hacer mejor es ajustar una interfaz de usuario alrededor de otro motor de procesamiento, aunque libera a los desarrolladores de la mayoría de las tareas de administración de memoria, por un precio. Si fuera yo, lo más probable es que haga un gran crujido en Perl (después de haber tenido que recodificar varios trozos de un sistema por lotes en Perl en lugar de Java en un trabajo anterior por motivos de rendimiento), luego escupí los resultados a tu código gráfico existente .

Sin embargo, dadas sus elecciones sugeridas, es probable que desee ir con la ruta SQL DB. Sólo asegúrese de que lo que realmente es más rápido durante unos consultas de ejemplo, ver los datos de la consulta de planta y todo lo que (suponiendo que su sistema de registro o de forma interactiva mostrar estos detalles)

Edición, (a Jim Ferrans) Objeto Java grande -N más rápido que Perl (comentario más abajo): los puntos de referencia a los que se hace referencia son principalmente pequeños bucles "aritméticos", en lugar de algo que hace unos cientos de MB de IO y lo almacena en un mapa /% hash/Dictionary/asociative-array para más tarde revisitando. Java I/O podría haber mejorado, pero sospecho que toda la abstracción lo hace comparativamente lento, y sé que el GC es un asesino. No lo he comprobado últimamente, no proceso archivos de datos de varios GB a diario en mi trabajo actual, como solía hacerlo.

Alimentar a los trolls (12/21): I measured Perl to be faster than Java for doing a bunch of sequential string processing. De hecho, dependiendo de qué máquina usé, Perl fue entre 3 y 25 veces más rápido que Java para este tipo de trabajo (lote + cadena). Por supuesto, la particular prueba de thrash-test que armé no implicaba ningún trabajo numérico, que sospecho que Java hubiera hecho un poco mejor, ni implicaba el almacenamiento en caché de una gran cantidad de datos en un Map/hash, que sospecho que Perl tendría hecho un poco mejor Tenga en cuenta que Java hizo mucho mejor en el uso de grandes cantidades de hilos, sin embargo.

Answer 5

Recomendaría ejecutar un generador de perfiles para ver qué parte del proceso de carga lleva más tiempo y si hay una posible optimización de ganancia rápida. Puede descargar una licencia de evaluación de JProfiler o YourKit.

Answer 6

Antes de tomar una decisión, probablemente valga la pena entender qué está pasando con su JVM, así como con los recursos de su sistema físico.

Hay varios factores que podrían estar en juego aquí:

• tamaño de almacenamiento dinámico de JVM
algoritmos de recolección de
• basura
• la cantidad de memoria física que han
• cómo cargar los datos - es lo desde un archivo que está fragmentado en todo el disco?
• ¿Por lo menos necesidad de cargar todos los datos a la vez - puede ser hecho que los lotes
• si usted lo está haciendo en lotes se puede variar el tamaño del lote y ver lo que sucede
• si el sistema tiene múltiples núcleos tal vez podría contemplar la utilización de más de un hilo a la vez para procesar los datos/carga
• si se utiliza ya múltiples núcleos y/S de disco es el cuello de botella, tal vez usted podría tratar de carga de diferentes discos al mismo tiempo

También debe consultar http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp si no está familiarizado con th e ajustes para la VM.