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.al...@gmail.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.al...@gmail.com> > >