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

Gracias Horacio por tus consideraciones adicionales....

...dudo que la cantidad de usuarios concurrentes sea mayor a 10.... y esta
data a ese nivel de detalle sólo va a entrar y no va a ser modificada ni
borrada (salvo la mayor a 3 meses..pero sería la eliminación de una tabla
completa considerando la solución de Álvaro.)... y el reporte (o dos) va a
tener seguramente dos parámetros.. nro.suscriptor y periodo de las
transacciones (intervalo de fechas)... asi que seguramente tendré que crear
dos índices sobre estas tablas particionadas..

Los otros reportes que sí son estadísticos (acumulativos, clasificados..)..
no me preocupan porque en otras plataformas ya hemos procesado ese volumen
de información..... pero primera vez que nos toca llevar TAL CANTIDAD de
detalle transaccional a la BD..

La finalidad de esta BD de reportes en mi humilde opinión no da para
DW....de hecho el concepto de particionamiento soluciona la situación que
plantié desde un principio.

Tengo que analizar los pros y contras tanto de postgres como de Oracle para
la implementación de esta característica.. considerando que esto también
pasa por decisiones comerciales seguramente se sentirán mas cercanos a la
solución de Postgres.

Tus recomendaciones de HW también me serán útiles para tratarlas con los
ingenieros de Soporte que son los encargados de habilitar las maquinitas..

Gracias.

Saludos
Andrés

El 11 de mayo de 2010 01:55, Horacio Miranda <hmiranda(at)gmail(dot)com> escribió:

> UIfff no tenia idea que postgres ya contaba con particionamiento,
> (tendre que leer y ponerme al día), sobre el hilo, solo te sugiero
> usar discos rapidos, de 15K y si tienes que generar un sistema de
> reportes que haga pedasos la maquina (como un datawarehause) la idea
> es que debes encolarlos, no permitas que las consultas sean en
> paralelo, deja lo resultados en tablas de resultados y crea una tabla
> de reportes (de esa forma el modelo toma uno por uno los
> requerimientos (esa tecnica se usa en los DW).
>
> Las tablas particionadas son utiles (las use cuando administraba una
> base de fotos para el gobierno de 9 Teras). Hoy ya va en 10T pero ya
> no la administro....
>
> Evita los full scan, pero si por ABC motivos no los puedes evitar
> revisa que el hardware sea el adecuado como una EVA 8000 o EVA 4000.
>
> Usar filesystem XFS (en lo personal lo encuentro más rapido) y ojo con
> las consultas mal hechas, si no se puede mejorar el codigo, revisa la
> posibilidad de crear indices de funciones (ignoro si se puede en
> postgresql) tendre que leer más.
>
> Evita usar arreglos RAID6... Usa RAID5 y de poder (si el presupuesto
> lo permite) usa RAID 0+1 (eso te da 4 ejes de lectura). Los discos WD
> de 6GB/s ya estan en el mercado Chileno y dan 120 MB/s si quieres
> hacer algo realmente rapido, hace un tiempo me parece que di un link
> de unos discos que dan 800 MB/s
>
> http://www.newegg.com/Product/Product.aspx?Item=N82E16820227498&cm_re=ocz_ssd-_-20-227-498-_-Product
>
> Espero que esto te ayude, pero recuerda que un buen modelo (no solo de
> datos) resuelve muchos problemas de performance. Solo piensa bien tu
> diseño y que resista 1 usuario, 3 usuarios y N usuarios, solo asi
> evitaras problemas de concurrencia. Espero que esto te ayude desde el
> punto de vista de infraestructura.
>
> 2010/5/8 Andrés P.P. <solopostgres(at)gmail(dot)com>:
> >
> > yap.. mis comentarios..
> >>
> >> 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/
> >
> >
> > Ahh.. ok.. en realidad fui inconsistente al pensar que tu propuesta de
> > modelo particionado lo podía "simular" separando tablas...y derivar la
> data
> > a una tabla especifica según la fecha del COPY.. pero por lo visto me
> > volé..............Ok!...... osea, debo ponerme a leer los links de
> herencias
> > y particionamiento...y evaluar el módulo que me indicas..
> >>
> >> 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?
> >
> >
> > En desarrollo sólo cuento con máquinas de 64bits, pero con S.O. de
> 32bits. y
> > 8GB en RAM... asi que tendré que probar ahí y extrapolar
> > proporcionalmente las estimaciones a un S.O. de 64 y 16 en RAM??...(sin
> > mencionar si el factor CPU tiene alguna gran incidencia..1,2,3....x
> core...)
> >
> >>
> >> 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.
> >
> >
> > Sip... las mediciones serán el mejor parámetro para tomar esa decisión..
> >
> > Gracias nuevamente... si tienes algún link de ejemplos de
> particionamiento
> > para irlo contrastando con la doc... se agradece.
> >
> > Saludos
> > AP.
> >
> >
>
>
>
> --
> Saludos,
> Horacio Miranda Aguilera.
> RedHat Certified Engineer
> DBA Oracle - Large databases
> +56 2 8974500
>