Foro - Perl en Español

Buenos días:

Estoy escribiendo un script que ejecuta una consulta contra una BD SQLite mediante unos datos que paso al mismo desde un frontal web. El script devuelve 5 bloques de datos numéricos que yo guardo en un array dentro de un hash. Combinados posteriormente en un solo array, estos datos me sirven para crear una respuesta HTML que es un listado de enlaces basados en los datos numéricos.

Como los listados son muy largos los quiero dividir y presentarlos en bloques de tal manera que el usuario pueda elegir ver del 1 al 100, del 101 al 200, etc., pulsando un enlace que pasará datos mediante un GET.

Mi consulta es: ¿en vuestra opinión sería mejor crear un objeto con todos los datos de la consulta y dividirlos y manipularlos desde el propio objeto o creo un xml que grabo en el servidor y lo voy leyendo conforme lo necesite? Los datos de la consulta podrían ser miles y no siempre el usuario los querrá leer todos.

Ignoro cuál podría ser más eficiente y rápido (a no ser que los desarrolle ambos y compare).

Gracias.
Javier.

Bienvenido a los foros de Perl en Español, Javier.

Creo que un parámetro que nos falta por saber es si puede actualizarse la base de datos mientras lo está viendo el usuario.

Si la BD no cambia, entonces sí que merece la pena guardar la consulta. Incluso se puede guardar más allá de cuando se haya ido el usuario. Hasta que la BD no cambie, no tendremos por qué hacer más consultas.

Eso es justo lo que hacen sistemas como memcached.

En Perl, hay varias opciones para serializar resultados, como el caso de las familias de módulos Cache y FileCache. Pero también está la opción de que nuestro programa esté funcionando de forma permanente, en cuyo caso el objeto puede estar en memoria.

Muchas gracias, explorer:

La BD no variará. Lo que me devuelve la consulta es una combinación de 5 campos que se relacionan entre ellos mediante booleanos y que salen de una BD que puede contener 2 millones de registros. Por eso me preocupa saber cuál es la parte crítica del modelo. Se me ocurrió al principio dividir los resultados de la consulta haciendo sucesivas consultas acotadas por un desplazamiento, pero creo que es repetir la misma consulta demasiadas veces para tanta información. Pensando en sacar todas la información en una sola consulta, intuyo que pierdo menos recursos. En cualquier caso, ¿los objetos en Perl pueden recoger grandes pilas de datos? Había pensado que si creo una "Consulta" y lo que me devuelve la propia consulta del usuario es muy pesado tal vez se ralentice la máquina.

Un saludo,
Javier.

Perl utilizará toda la memoria disponible para almacenar la estructura de datos, así que por ahí ya tienes un límite físico. Límite que es fácil de saltar si usamos técnicas de mapeado de memoria (mmap). Una vez que la estructura esté en memoria, el acceso a un dato concreto depende de la velocidad del procesador. Ya que la mayor parte de las veces la estructura de datos estará indexada según el tipo de acceso a la clave principal (numérico, entonces podemos pensar en usar un array, o por cualquier otra cosa, por lo que usaremos un hash), el acceso a la información será más rápido (generalmente) que la que ofrece el propio motor de búsqueda (aquí habría que hacer pruebas de rendimiento, ya que hay motores muy optimizados, sobre todo en consultas indexadas y cacheadas).

Es difícil saber la parte crítica si no contamos con los números, para echar las cuentas.

Voy a ponerte un caso parecido.

En una ocasión, tenía que hacer una consulta enorme para sacar una serie de estadísticas, y crear una hoja Excel con ellas. Para ello, contaba con un Windows XP en una máquina con 2 GB de RAM.

El servidor de base de datos tardaba más de 40 segundos en devolver la consulta, que consistía en millones de líneas, que se transmitían por la red local. Al ordenador llegaban unos 200 MB de datos.

40 segundos era algo inaceptable, ya que la consulta debía resolverse lo más rápidamente posible para entregar el resultado al usuario. Después de optimizar la consulta con un experto en SQL, se redujo bastante el tiempo de la consulta, pero no el del tiempo de transmisión, así que decidí hacer la siguiente jugada: reducir la consulta a un simple SELECT * FROM ... es decir: no hay consulta, quería leer TODA la base de datos a memoria, y sería mi programa el que se encargase de "hacer la consulta". El resultado es que se redujo a cero el tiempo de la consulta en el motor de la base de datos, y aumentó el de transmisión a mi ordenador, pero una vez recreada la información en la memoria, en forma de estructuras Perl, el acceso a cualquier parte de la información era rapidísimo.

Así que la solución fue esa: se arranca el programa, se descarga la base de datos, y a partir de ese momento queda esperando las consultas de los clientes. Se obtienen respuestas inmediatas a costa de consumir RAM de forma permanente.

Otro detalle fue el cambio de sistema operativo. Pasando de Windows a Linux (en el mismo hardware) obtuvimos una mejora en la creación de la estructura en memoria de diez (¡10!) veces.

Así que... al final ya ves que hay que hacer pruebas, pero, si tienes a tu disposición una buena máquina, pregunta al administrador del sistema si puedes "ocupar todos los recursos" de esa máquina

Es muy normal, en informática, hacer el trueque de CPU <-> RAM para resolver este tipo de problemas.

Muchas gracias, explorer:

Voy a probar. Tengo suerte y todo se va a desarrollar en una máquina Linux, porque me consta que Windows es otro mundo. El único pero es que el administrador me dice que siendo una máquina Linux, podría suceder que me asignen una capa de máquina virtual para hacerlo en cuyo caso tengo la variable máquina real y máquina virtual, además del modelo lógico de la propia aplicación.

Javier