Manejar grandes cantidades datos

[elangelcaido]

Hola,

Me gustaría saber la mejor manera de manejar grandes cantidades de datos obtenidos de una base de datos. ¿qué supone menos carga para un servidor web, estar haciendo consultas, no demasiado complejas, cada poco para obtener los datos ó obtener una gran cantidad de datos y grabarlos, por ejemplo, en un archivo XML para trabajar haciendo consultas de datos, etc.?.
La situación sería acceder a una base de datos que está en la misma máquina donde esta corriendo el programa que se ejecuta.

Esta pregunta la oriento a la programación desde JAVA, mayormente, pero creo que se podría ampliar a otros leguajes de programación, por ejemplo, otros más orientados a la web como PHP.

Gracias por la ayuda.

[matanga]

Hola,

Las variantes son muchas, no se si existe una respuesta directa para este caso, depende del modelo de datos, de la cantidad de conexiones/operaciones/transacciones, usuarios, etc.

Yo soy de la idea de que los datos van en la base de datos, hasta ahora no vi la necesidad real de mantener informacion en XML fuera de la base, aun cuando en este momento me toca administrar un sistema que hace exactamente eso, 70% en la base y 30% en XML.

Un par de cosas a tener en cuenta:

1. Es necesario que la informacion este en formato XML?, si es asi, hoy en dia varios motores de base de datos estan haciendo un esfuerzo muy grande para dar soporte XML dentro de la base, implementando XQuery y XPath, y por las pruebas de rendimiento que he realizado, no creo que ninguna aplicacion supere la velocidad de la base de datos, esto lo digo sin desmerecer tus habilidades como programador.

2. Si alamcenas la informacion en XML fuera de la base, pierdes todas las ventajas de los modelos de cache que dan las bases de datos, tecnologia que lleva años evolucionando.

3. A menos que lo desarrolles o que los datos en XML sean de solo lectura, pierdes la capacidad de proteger los datos mediante transacciones cuando los usuarios hagan modificaciones.

4. Tienes la informacion dividida, lo que te da un grado mas de tareas de administracion, esto lo digo pensando en backup y recuperacion.

5. Tienes la sobrecarga de generar/actualizar los XML, aunque no se donde estara la inforamcion inicialmente.

6. Denende del sistema operativo con el que trabajes, pero la mayoria de los filesystems carecen de indices, por lo tanto es probable que sea mas lenta la busqueda de datos en el sistema operativo que dentro de una base de datos, esto esta sujeto a la cantidad de ficheros XML que tengas.

En fin, podria seguir enumerando, pero me doy cuenta que solo digo las contras y no las ventajas :)

Saludos

[wwwmaster]

En general, si la databse radica en la misma maquina, no debes tener problemas de rendimiento, pero si deseas hacerlo de una manera correcta, esto es lo que debes evitar:
- Se ejecutan selecciones de datos sin filtrar los campos que únicamente deben requerirse para el despliegue de secciones, lo cual afecta directamente el rendimiento de la base de datos.
http://www.edbarlow.com/document/optimize.htm
(apartado: “Efficient Query Design”)

- No existen índices creados que permitan un acceso más rápido a la base de datos como es el caso de ordenamiento de datos por nombre o descripción (por ejemplo en “carreras”, “articulos”).
http://msdn2.microsoft.com/en-us/library/aa964133.aspx

- Se genera una única conexión al inicio de la aplicación en el archivo “global.asa” la cual es reutilizada por prácticamente todo el sitio, siendo que la recomendación de Microsoft es abrir una conexión y cerrarla cada vez que se requiera.
http://www.microsoft.com/technet/pro...ips.mspx#EUAAC


- No se hace uso de la propiedad “cachesize” al acceder al Sql Server, con lo que cada registro regularmente debe ser recuperado del Sql Server
http://www.argentina-hosting.com/art...atos/index.htm
(apartados 12 y 13)

- No se hace uso de “Stored Procedures” los cuales, al ser consultas precompiladas en el Sql Server permiten una recuperación de datos más eficiente.
http://www.developerfusion.co.uk/show/5855/