FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Me encantará conocer ¿Colombia?, aunque seguro que encuentras ayuda profesional en tu ciudad
|
#2
|
||||
|
||||
Resolver cualquier problema de desempeño empieza siempre por averiguar *exactamente* donde esta el problema. No es cosa de adivinar y ver que sale.
Luego en medir como estan las cosas: http://wiki.postgresql.org/wiki/Using_EXPLAIN Luego esta en revisar si la forma de atacar el problema es correcta, y de ser posible, simplificar y simplificar. Por regla general, el mayor avance se logra en este punto. Luego esta en usar la herramienta/tecnica adecuada para la situacion. Por regla general, la mayor eficacia se logra en este punto. Luego en volver a medir y ver si se arreglo el asunto. Por ultimo (a menos que las pesquizas den lo contrario) esta en hacer ajustes de hardware. Lo que implica saber exactamente como usa el hardware el software en question. Por ejemplo, muchos se fijan solo en lo rapido de su CPU, y no en el I/O ni en la memoria. Otros no piensan en los valores de cache, ni en como usar las conexiones, ni muchos otros factores. P.D: Una cosa que quiero recalcar, que pense al leer: Cita:
Un ejemplo, de hace años cuando hacia un software de calificacion de colegios, era que generar los reportes con las notas y editar las notas era un trabajo complicado, lento y lleno de errores y casos especiales. Un dia, viendo el formato que se usa para hacer eso a mano, pense: "Porque no mejor haga la tabla *exactamente* como se ve aqui impreso? -en vez de seguir con las tablas normalizadas tal como siempre ha sido-" Y !puff! empezo todo a salir bien
__________________
El malabarista. Última edición por mamcx fecha: 22-02-2014 a las 20:20:58. |
#3
|
|||
|
|||
Recomiendo un DBA
No es el problema PostgreSQL, para nada, no solo que esta hecho para ese nivel de requerimientos sino que es una de las mejores opciones para aplicaciones de alta criticidad. Por otro lado no se puedo opinar sin tener datos de equipos, estructura de las tablas, consultas, parametros de configuracion de la base, etc. Los motores destinados a grandes volumenes de datos, y muchos usuarios concurrentes, postgres, oracle, db2, sqlserver, etc. si al instalarlos hacemos next next next, andara, pero sera mas o menos como mysql u otros motores que no nombro para no ofender. La gran ventaja que tienen los grandes motores es brindar una amplia posibilidad de hacer tunning que los mas pequeños no tienen, por lo que la diferencia luego de manos expertas analizando el problema puede ser muy significativa
|
#4
|
|||
|
|||
Velocidad de Respuesta
Hola , quisiera preguntarte si lees un solo (1) registro cuanto demora la consulta?
porque si toma menos tiempo de 10 minutos puede ser el alto numero de registros que retornas en la consulta |
#5
|
||||
|
||||
Cuando manejas esos volumenes debes comenzar a dar mas importancia a todos los detalles, desde la forma como construyes un select, por ejemplo: el orden de las tablas, de los campos, las llaves que utilizas... no solo de los indices.
Debes ademas hacer tunning al motor, revisar el canal y el servidor. Normalmente una empresa que maneja estas transacciones debe contemplar una infraestructura que lo soporte(datacenters, cloud..) Y de tu parte queda ademas, revisar si estas haciendo consultas desde un cliente difectamente, o si el trabajo duro de las consultas se hacen en el servidor Por otro lado, debes pensar de una vez en la posibilidad de partir o distribuir tu db, para que solo maneje la transaccionalidad critica y las consultas historicas se hagan hacia un repositirio diferente. Debes calcular el crecimiento a un año como minimo, y como se haria el ba,ckup y fraccionamiento anual. En fin |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Insert masivo de datos, cada vez mas lento | papote654 | MS SQL Server | 14 | 16-05-2012 18:02:17 |
Problema de Tipo de datos - PostgreSQL | SEBACOHEN | Conexión con bases de datos | 2 | 30-08-2008 02:17:17 |
Base de datos PostgreSQL de 474 Gb | Casimiro Notevi | La Taberna | 24 | 29-04-2008 21:11:27 |
como hago para agregar datos a PostgreSQL | pnsd_89 | Conexión con bases de datos | 0 | 22-03-2007 18:56:04 |
Barridos de Base de Datos Lento | jmedina | Conexión con bases de datos | 3 | 16-08-2004 01:40:38 |
|