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. <solopostg...@gmail.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 - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
