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

Excerpts from Andrés P.P.'s message of vie may 07 11:45:36 -0400 2010:

> 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..

No, para nada. Tú haces una consulta sobre tabla_todos_meses con un WHERE fecha=...
y automáticamente postgres se encarga de usar sólo las tablas de esos meses.
(Lee sobre el parámetro constraint_exclusion en la documentación)

Por otra parte, considera que si el número de teléfono es una constante, esa
consulta usará un índice en cada tabla para buscar sólo los registros de ese
teléfono, y por lo tanto no tiene que recorrer los 600 millones de registros en
cada tabla.

Otra cosa que te puede interesar es este módulo para manejar prefijos; lo
escribió Dimitri Fontaine precisamente para manejar datos telefónicos.
http://prefix.projects.postgresql.org/

> 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..

Hoy en día no tiene sentido poner una base de datos de un tamaño "grande"
en un servidor que no sea de 64 bits. Me imagino que mínimo estarás pensando
en usar unos 16 GB de memoria, cierto?

> 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..)..

No, borrar y crear índices no requiere vacuum.

Sobre si es mejor dejar el índice o reconstruirlo durante la carga masivo,
es algo que deberías medir. Creo que en algunos casos puede ser mejor
borrarlos y en otros dejarlos.

Si es algo que te complica mucho, quizás podrías hacer tablas por semanas
en lugar de tablas por meses.

> 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.

En Postgres el particionamiento está basado en herencia.
--