Hola, les escribo para ver si me pueden ayudar con el siguiente problema:
Tengo un proceso de conciliación de suscriptores que corre sobre Perl en un servidor UNIX; el proceso consiste en leer un archivo .txt (de 1.000.000 de registros) que contiene toda la información a conciliar y compara con los registros que están en 2 tablas en la BD (cada una con alrededor de 14.000.000 de registros). Las tablas tienen los índices necesarios para que las búsquedas sean rápidas y se ejecutan 4 procesos en paralelo con 250.000 registros.
El problema es que este proceso está tardando demasiado (alrededor de 19 horas) y este mismo proceso debe repetirse después para 13 millones de clientes (lo cual serían unos 11 días ejecutando el proceso).
Necesito saber si existe alguna forma de acelerar el proceso para que tarde mucho menos y se pueda ejecutar el proceso completo para los 14 millones de registros en máximo 2 días.
Gracias de antemano.
-
- Publicidad
Conciliación en Perl tarda demasiado
3 mensajes
• Página 1 de 1
Conciliación en Perl tarda demasiado
por gisulan » 2011-08-17 14:36 @650
- gisulan
- Perlero nuevo
- Mensajes: 1
- Registrado: 2011-08-17 14:30 @646
Publicidad
Re: Conciliación en Perl tarda demasiado
por pvaldes » 2011-08-17 17:47 @782
La palabra clave es database probablemente, estás comparando 1 millón de registros uno a uno... ¿con qué código exactamente?
> Necesito saber si existe alguna forma de acelerar el proceso.
Puede que tu código no sea óptimo, habría que verlo al menos...
Puede que tu database no sea muy rápida, o no esté bien configurada... habría que saber algo más sobre ella...
Y si no quieres dar esa información en un foro público lo mejor probablemente sería plantearte subcontratar a algún profesional para ese tipo de trabajo. ¿Por qué digo ésto...? me explico:
Limpiar tu código aun con todos los datos puede llevar horas, probablemente muy por encima del espíritu de lo que viene a ser un foro gratuito, y además entiendo que estás cobrando por hacer ese trabajo para una empresa de 14 millones de clientes, un consejo equivocado por nuestra parte (no sería raro teniendo en cuenta que estamos valorando un problema, del que ¡no sabemos apenas nada!) aun siendo bienintencionado puede hacer que tu empresa pierda mucho dinero. Yo no perdería tiempo y trataría directamente con un experto, con un contrato de por medio que te dé ciertas garantías de que tu sistema no va a estar parado cuatro días mientras hacemos sugerencias a ciegas.
Ojo, probablemente sea el mismo experto que te pueda estar contestando aquí, pero bajo otras condiciones. Lo que quiero decir es que ésto no lo puedes enfocar como algo voluntario y amateur, yo al menos no lo haría (y desde luego tampoco estoy intentando hacerte creer que me presento voluntario para solucionarte ese marrón por dinero).
En cualquier caso ese sistema híbrido personalmente... no me gusta. Yo crearía una tabla con el archivo de texto y aprovecharía la posibilidad de indexar esa tabla.
> Necesito saber si existe alguna forma de acelerar el proceso.
Puede que tu código no sea óptimo, habría que verlo al menos...
Puede que tu database no sea muy rápida, o no esté bien configurada... habría que saber algo más sobre ella...
Y si no quieres dar esa información en un foro público lo mejor probablemente sería plantearte subcontratar a algún profesional para ese tipo de trabajo. ¿Por qué digo ésto...? me explico:
Limpiar tu código aun con todos los datos puede llevar horas, probablemente muy por encima del espíritu de lo que viene a ser un foro gratuito, y además entiendo que estás cobrando por hacer ese trabajo para una empresa de 14 millones de clientes, un consejo equivocado por nuestra parte (no sería raro teniendo en cuenta que estamos valorando un problema, del que ¡no sabemos apenas nada!) aun siendo bienintencionado puede hacer que tu empresa pierda mucho dinero. Yo no perdería tiempo y trataría directamente con un experto, con un contrato de por medio que te dé ciertas garantías de que tu sistema no va a estar parado cuatro días mientras hacemos sugerencias a ciegas.
Ojo, probablemente sea el mismo experto que te pueda estar contestando aquí, pero bajo otras condiciones. Lo que quiero decir es que ésto no lo puedes enfocar como algo voluntario y amateur, yo al menos no lo haría (y desde luego tampoco estoy intentando hacerte creer que me presento voluntario para solucionarte ese marrón por dinero).
En cualquier caso ese sistema híbrido personalmente... no me gusta. Yo crearía una tabla con el archivo de texto y aprovecharía la posibilidad de indexar esa tabla.
- pvaldes
- Perlero nuevo
- Mensajes: 129
- Registrado: 2011-01-22 12:56 @580
Re: Conciliación en Perl tarda demasiado
por explorer » 2011-08-17 19:11 @841
Bienvenido a los foros de Perl en español, gisulan.
Yo intentaría hacer todo el proceso en memoria.
Ya me he enfrentado con problemas así, y el hacer las consultas a la base de datos era el cuello de botella, porque se hacían millones de consultas.
Se probó también a realizar consultas SELECT con JOIN (varios JOIN...) y nada... el motor de base de datos tardaba un montón (en un maquinón IBM de nosecuántos Gb de memoria y *pocos* Ghz...)
El trabajo consistía en hacer consultas en tres bases de datos distintas, y encontrar información dispar para representar los resultados en una tabla Excel, como informe de errores de consolidación entre las bases de datos.
La solución fue sencilla: solo una consulta por cada base de datos para traer *toda* la información que nos interesaba mirar (solo los campos de cada registro que íbamos a comparar). Meter la información recuperada de la base de datos en estructuras hash y array (se elige uno u otro según fuéramos a acceder a la información de forma indexada o por clave). Y hacer que todo el trabajo de búsqueda y comparación lo haga la máquina.
Un PC normal, con 3Gb, a 2Ghz, procesó 3 millones de registros en poco más de veinte minutos.
Bueno, y eso porque estaba en Windows. Cuando lo pasamos a Linux tardó 6 minutos
Hace falta un poco más de información, para detallar un poco más.
Y si quieres contratarme (como dice pvaldes
) mándame un mensaje privado
Aunque *siempre* puedes preguntar aquí todo lo que quieras.
Yo intentaría hacer todo el proceso en memoria.
Ya me he enfrentado con problemas así, y el hacer las consultas a la base de datos era el cuello de botella, porque se hacían millones de consultas.
Se probó también a realizar consultas SELECT con JOIN (varios JOIN...) y nada... el motor de base de datos tardaba un montón (en un maquinón IBM de nosecuántos Gb de memoria y *pocos* Ghz...)
El trabajo consistía en hacer consultas en tres bases de datos distintas, y encontrar información dispar para representar los resultados en una tabla Excel, como informe de errores de consolidación entre las bases de datos.
La solución fue sencilla: solo una consulta por cada base de datos para traer *toda* la información que nos interesaba mirar (solo los campos de cada registro que íbamos a comparar). Meter la información recuperada de la base de datos en estructuras hash y array (se elige uno u otro según fuéramos a acceder a la información de forma indexada o por clave). Y hacer que todo el trabajo de búsqueda y comparación lo haga la máquina.
Un PC normal, con 3Gb, a 2Ghz, procesó 3 millones de registros en poco más de veinte minutos.
Bueno, y eso porque estaba en Windows. Cuando lo pasamos a Linux tardó 6 minutos
Hace falta un poco más de información, para detallar un poco más.
Y si quieres contratarme (como dice pvaldes
) mándame un mensaje privado Aunque *siempre* puedes preguntar aquí todo lo que quieras.
JF^D Perl programming & Raku programming. Grupo en Telegram: https://t.me/Perl_ES
-
explorer - Administrador
- Mensajes: 14480
- Registrado: 2005-07-24 18:12 @800
- Ubicación: Valladolid, España
3 mensajes
• Página 1 de 1
¿Quién está conectado?
Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 8 invitados