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

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