FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Muchas Gracias casimiro entonces seguiré adelante sin temor y revisare mas bien el hardware y los ajustes en la base de datos.
Una ultima pregunta, cuanto tarda en promedio una consulta sobre las tablas de movimiento de la base datos firebird que comentas. Segundos, Minutos ??? Si tenemos en cuenta que google tiene miles de millones de datos y si hacemos una consulta muestra milllones de resultados a una velocidad que no supera 1 segundo. Mil Gracias.
__________________
JaiMelendez |
#2
|
||||
|
||||
Milésimas de segundo.
Pero es que estamos hablando sin conocer nada de tu sistema. |
#3
|
|||
|
|||
mi sistemas es una aplicación web y esta en pruebas, para la cual creé 20 tablas (las que mas tienen movimiento) y les ingrese 600.000.000 de registros ya que esto seria un mes de trabajo según el proyecto.
La cuestion es que ingrese estos datos y decidí realizar una consulta y esta tardo mas de 10 minutos en ejecutarse. este sistema sera instalado a muchos clientes, unos ingresan mucha información otros mucho menos, entonces no es lógico que un usuario que ingrese 20 o 30 registros diarios tenga que esperar mas de 10 minutos esperando un informe. El reto es que todas las consultas que se realicen no superen el segundo ese es el objetivo.
__________________
JaiMelendez |
#4
|
||||
|
||||
Habría que estudiar bien el caso para afinar lo más posible.
De todas formas, la mayor o menor velocidad en responder una consulta sql no depende básicamente de que tengas más o menos millones de registros, porque para eso son los índices, casi no importa la cantidad de registros. Ya digo, habría que estudiar muy bien tu sistema. El cuello de botella puede estar en cualquier sitio, software, hardware, red, internet... no podemos saberlo si no lo podemos verificar, |
#5
|
|||
|
|||
Gracias Casimiro, una ves diseñe todo el sistema y haga todas las pruebas y ajustes y vea que el rendimiento no es optimo, me pondre en contacto con usted para ver si es posible visitarnos.
Gracias.
__________________
JaiMelendez |
#6
|
||||
|
||||
Me encantará conocer ¿Colombia?, aunque seguro que encuentras ayuda profesional en tu ciudad
|
#7
|
||||
|
||||
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. |
|
|
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 |
|