Re: [pgsql-es-ayuda] Diseño para una BD con muchos registros...

Hola.... ayer ya era tarde cuando les escribí, asi que recién vengo
leyendo..

Gracias Javier por la respuesta, pero sin haber trabajado en DW tengo
entendido que ésta es una estructura que es Construida y se orienta para
análisis (a grandes rasgos), pero mi caso es prácticamente un vaciado desde
un archivo a una (o más) tablas para que después a través de un reporte con
uno o dos parámetros vaya y traiga los registros asociados...... osea, aca
no hay agrupamiento, ni clasificaciones especiales como en los demás
reportes que los tendré en otras tablas... pero repito, gracias.... es una
area interesante para explorar para otros proyectos que tengo.

Alvaro, si bien es cierto tu respuesta "me alegra" en el sentido de lo
simple que aparentemente resulta implementarlo me cuesta pensar que 600
millones de datos en una tabla no sea demasiado.....como decía, las
dimensiones con las que he trabajado siempre han sido pequeñas......pero
obviamente confío en tu opinión. Ahora, pensando en que los parámetros
bajo los cuales funcionará el reporte es un número de teléfono y un
intervalo de fechas.. y al cliente se le ocurre solicitar las llamadas en
los últimos 3 meses..... eso implicaría algo del tipo...

select ...data... from tabla_mes1 where phone_number=param_rep
union
select ...data... from tabla_mes2 where phone_number=param_rep
union
select ...data... from tabla_mes3 where phone_number=param_rep
order by fecha_data..

.... aquí se me generan dos aspectos a analizar...

1: el tiempo de respuesta.. la búsqueda podría ser sobre 600 o sobre 1800..
Me pueden recomendar características de HW en cuanto a CPU y RAM..un
estimativo solamente para no bajar de eso.... también he leido que se hace
cada vez más frecuentes los S.O de 64bits... me lo recomiendan??.. hasta
ahora nuestras plataformas han trabajado con 32bits.....pero he visto en el
foro que los de 32 tienen limitantes al configurar shared_buffers por
ejemplo..

2: ..pensando en que este proceso de copia diaria es una vez al día y
seguramente sería tipo 1:00 a.m. cuando no hay actividad..........en estas
tablas tendría un índice para phone_number..y otro seguramente por
fecha_data (para cuando pidan intervalos pequeños...)......me recomiendan
mantener los índices en cada copia diaria de 20 millones o borrarlos antes y
reconstruirlos después de cada copia??..... de ser así al final del mes
tendría que construir dos índices sobre 600 millones....no tomaría
mucho?.... y por último, en el caso de borrar y crear el índice diariamente,
no se requiere vacuum?? (yo siempre lo he asociado a deletes y updates
sobre tablas solamente..)..

Finalmente, Manuel.. gracias también por tu respuesta, no he trabajado con
herencias asi que leeré tus links para hacerme una idea de tu propuesta y
complementarla a lo que propone Álvaro.

Gracias a todos..

Saludos
Andrés

El 7 de mayo de 2010 09:23, Manuel Fernando Aller
<manuel(dot)aller(at)gmail(dot)com>escribió:

> El jue, 06-05-2010 a las 21:20 -0400, Alvaro Herrera escribió:
> > Excerpts from Andrés P.P.'s message of jue may 06 17:42:28 -0400 2010:
> >
> > > Sin embargo, se presentó un proyecto para una BD de reportes muy
> similar a
> > > los que ya manejo....pero existe una alta probabilidad que el cliente
> > > insista en solicitar un reporte que requiera listar el detalle de estas
> > > transacciones bajo algún criterio de identificación...... Para ello
> > > requiero insertar cada uno de estos 20 millones de registros a la
> BD....lo
> > > que al mes me significaría 600 millones... y tomando en cuenta un
> histórico
> > > estandar de 3 meses... 1800 millones de registros presentes en la BD
> luego
> > > de 3 meses de uso......
>
> > Suena como la tarea perfecta para un modelo particionado por mes. 600
> millones
> > de registros en una tabla no es tan descabellado. Y limpiar cada tres
> meses
> > significa hacer TRUNCATE en la partición más antigua. Ni siquiera
> necesitas
> > hacer VACUUM.
>
> O peor, 'alter table parteMesADescartar NO inherit tablaTotal'
>
> :-P
>
> Y después, si tiene ganas,
> 'drop table parteMesADescartar'
>
> fijate en http://www.postgresql.org/docs/current/static/ddl-inherit.html
> y en http://www.postgresql.org/docs/current/static/ddl-partitioning.html
>
> Saludos!
>
>
> --
> Manuel Fernando Aller <manuel(dot)aller(at)gmail(dot)com>
>
>