Foro - Perl en Español

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.

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.