Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Bases de datos > PostgreSQL
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 22-02-2014
JAI_ME JAI_ME is offline
Miembro
 
Registrado: ene 2006
Posts: 188
Poder: 19
JAI_ME Va por buen camino
Base de Datos PostgreSql Lento

tengo varias tablas relacionadas en postgreSQL, dos de ellas son de mucho movimiento aproximadamente 20.000.000 registros insertados diariamente (sin contar las modificaciones y eliminaciones). Este es un estimado que he calculado y seria el maximo de registros diarios que se ingresarian en mi base de datos cuando comience a funcionar.

A manera de ejemplo inserte por medio de ciclos 600.000.000 de registros que serian los movimientos de un mes en las dos tablas de movimientos y al tratar de hacer una consulta se tarda muchisimo tiempo en mostrar el resultado, cree varios indices que me mejoraron la velocidad pero sigue siendo demasiado lenta una consulta.

Sera que postgreSQL no soporta una consulta de esta magnitud que tal con informacion de 3,4 o 5 años.

No me quiero imaginar.

Que me recomiendan o debo cambiar de RDBMS.

Mil Gracias.
__________________
JaiMelendez
Responder Con Cita
  #2  
Antiguo 22-02-2014
avmm2004 avmm2004 is offline
Miembro
 
Registrado: jun 2006
Ubicación: Santa cruz de Tenerife, Islas Canarias
Posts: 500
Poder: 18
avmm2004 Va por buen camino
Para esos volúmenes de datos, mejor Oracle. Yo la tengo funcionando en un cliente con unos volúmenes parecidos (un poco inferiores) y las respuestas después de 7 años son inmediatas.

Haz el mismo test que con postgresql, es la mejor recomendación.
Responder Con Cita
  #3  
Antiguo 22-02-2014
Avatar de Casimiro Notevi
Casimiro Notevi Casimiro Notevi is offline
Moderador
 
Registrado: sep 2004
Ubicación: En algún lugar.
Posts: 32.021
Poder: 10
Casimiro Notevi Tiene un aura espectacularCasimiro Notevi Tiene un aura espectacular
La solución no es cambiar a Oracle, para nada.

Lo que tienes que hacer es buscar el culpable de la lentitud, verificar qué campos intervienen en la consulta, qué índices usa, cual de ellos es necesario y cual no, mirar si hay otra forma de hacer la consulta, etc.
Y además, por supuesto, habrá que ver qué hardware estás usando, qué sistema, qué memoria, qué buffers, qué cachés, qué espacio de memoria temporal, qué discos qué velocidad, qué procesadores, cuántos, cómo trabajan, qué sistema operativo, cómo está configurado, qué red, qué cableado, qué routers, etc. etc. etc. etc. etc.

PostgreSql NO es más lento que Oracle, o sea, que la solución no es cambiar a Oracle, la solución es resolver el problema, y para ello tienes que encontrar el problema.

Última edición por Casimiro Notevi fecha: 22-02-2014 a las 21:50:37.
Responder Con Cita
  #4  
Antiguo 22-02-2014
JAI_ME JAI_ME is offline
Miembro
 
Registrado: ene 2006
Posts: 188
Poder: 19
JAI_ME Va por buen camino
muchas gracias a los dos por sus opiniones, voy a validar indices y lo que dice casimiro. aunque pense por un momento migrar a SqlServer u Oracle.

Que otras opiniones me pueden dar.

gracias.
__________________
JaiMelendez
Responder Con Cita
  #5  
Antiguo 22-02-2014
Avatar de Casimiro Notevi
Casimiro Notevi Casimiro Notevi is offline
Moderador
 
Registrado: sep 2004
Ubicación: En algún lugar.
Posts: 32.021
Poder: 10
Casimiro Notevi Tiene un aura espectacularCasimiro Notevi Tiene un aura espectacular
Cita:
Empezado por JAI_ME Ver Mensaje
.. aunque pense por un momento migrar a SqlServer u Oracle.
Ni se te ocurra, no vas a ganar nada, más bien al contrario, te gastarás mucho dinero en licencias, y en hardware para hacerlo funcionar.

Cita:
Empezado por JAI_ME
Que otras opiniones me pueden dar.
Para que te hagas una idea de que la solución no es cambiar postgresql, algunos empresas que he atendido tienen requerimientos similares a los que comentas e incluso, más, y sin embargo trabajan perfectamente con Firebird. Eso sí, la base de datos bien afinada, una buena red local, un servidor linux con varias cpus y mucha memoria ram, discos duros muy rápidos, etc.
Responder Con Cita
  #6  
Antiguo 22-02-2014
JAI_ME JAI_ME is offline
Miembro
 
Registrado: ene 2006
Posts: 188
Poder: 19
JAI_ME Va por buen camino
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
Responder Con Cita
  #7  
Antiguo 22-02-2014
Avatar de Casimiro Notevi
Casimiro Notevi Casimiro Notevi is offline
Moderador
 
Registrado: sep 2004
Ubicación: En algún lugar.
Posts: 32.021
Poder: 10
Casimiro Notevi Tiene un aura espectacularCasimiro Notevi Tiene un aura espectacular
Milésimas de segundo.

Pero es que estamos hablando sin conocer nada de tu sistema.
Responder Con Cita
  #8  
Antiguo 22-02-2014
JAI_ME JAI_ME is offline
Miembro
 
Registrado: ene 2006
Posts: 188
Poder: 19
JAI_ME Va por buen camino
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
Responder Con Cita
  #9  
Antiguo 22-02-2014
Avatar de Casimiro Notevi
Casimiro Notevi Casimiro Notevi is offline
Moderador
 
Registrado: sep 2004
Ubicación: En algún lugar.
Posts: 32.021
Poder: 10
Casimiro Notevi Tiene un aura espectacularCasimiro Notevi Tiene un aura espectacular
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,
Responder Con Cita
  #10  
Antiguo 22-02-2014
JAI_ME JAI_ME is offline
Miembro
 
Registrado: ene 2006
Posts: 188
Poder: 19
JAI_ME Va por buen camino
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
Responder Con Cita
  #11  
Antiguo 22-02-2014
Avatar de Casimiro Notevi
Casimiro Notevi Casimiro Notevi is offline
Moderador
 
Registrado: sep 2004
Ubicación: En algún lugar.
Posts: 32.021
Poder: 10
Casimiro Notevi Tiene un aura espectacularCasimiro Notevi Tiene un aura espectacular
Me encantará conocer ¿Colombia?, aunque seguro que encuentras ayuda profesional en tu ciudad
Responder Con Cita
  #12  
Antiguo 22-02-2014
Avatar de mamcx
mamcx mamcx is online now
Moderador
 
Registrado: sep 2004
Ubicación: Medellín - Colombia
Posts: 3.911
Poder: 25
mamcx Tiene un aura espectacularmamcx Tiene un aura espectacularmamcx Tiene un aura espectacular
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:
A manera de ejemplo inserte por medio de ciclos 600.000.000 de registros que serian los movimientos de un mes
A veces los problemas surgen porque uno se aferra a hacer las cosas de una manera, y luego espera que salgan de otra (meter un cuadrado dentro de un circulo). Es mejor preguntarse: Es realmente necesario lo que estoy haciendo? Porque estoy metido en este lio? Porque estoy aferrado a como son las cosas *ahora*? SI tengo el poder, que puedo hacer para cambiar el problema hasta que sea algo trivial de resolver?

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 21:20:58.
Responder Con Cita
  #13  
Antiguo 25-02-2014
vhr vhr is offline
Miembro
 
Registrado: feb 2005
Ubicación: Argentina- Buenos Aires- Quilmes
Posts: 28
Poder: 0
vhr Va por buen camino
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
Responder Con Cita
  #14  
Antiguo 25-02-2014
ASAPLTDA ASAPLTDA is offline
Miembro
 
Registrado: jun 2003
Ubicación: COLOMBIA-CALI
Posts: 639
Poder: 21
ASAPLTDA Va por buen camino
Smile 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
Responder Con Cita
  #15  
Antiguo 13-03-2014
Avatar de gatosoft
[gatosoft] gatosoft is offline
Miembro Premium
 
Registrado: may 2003
Ubicación: Bogotá, Colombia
Posts: 833
Poder: 21
gatosoft Va camino a la fama
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
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Insert masivo de datos, cada vez mas lento papote654 MS SQL Server 14 16-05-2012 19:02:17
Problema de Tipo de datos - PostgreSQL SEBACOHEN Conexión con bases de datos 2 30-08-2008 03:17:17
Base de datos PostgreSQL de 474 Gb Casimiro Notevi La Taberna 24 29-04-2008 22:11:27
como hago para agregar datos a PostgreSQL pnsd_89 Conexión con bases de datos 0 22-03-2007 19:56:04
Barridos de Base de Datos Lento jmedina Conexión con bases de datos 3 16-08-2004 02:40:38


La franja horaria es GMT +2. Ahora son las 17:04:25.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi