Tengo una gran cantidad de datos del modelo meteorológico que se ponen en una base de datos PostgreSQL. La máquina tiene 8 núcleos y 16 GB de RAM. Estoy ejecutando PostgreSQL 9.3 con PostGIS 2.1. Cada tabla tendrá una variedad diferente de datos meteorológicos (temperatura, punto de rocío, viento, etc.). Cada tabla tendrá 6-7 columnas: latitud, longitud, geometría del punto, elevación, fecha-hora para la que el modelo es relevante y 1-2 valores de datos de interés. Los datos se consultarán principalmente para un cuadro delimitador por tiempo y elevación. Habrá aproximadamente 145,757,360 filas por tabla (los datos anteriores a ahora ya no serán relevantes se eliminarán). Estimo que el tamaño de las tablas es de aproximadamente 10 GB cada una sin índices. (Eso es 52 bytes de datos más 23 bytes de sobrecarga por fila). Los datos se actualizarán / insertarán periódicamente a medida que se disponga de nuevos datos del modelo. Nota:
Así que estoy mirando estos dos planes:
- Simplemente indexe y agrupe por (fecha hora, elevación) con un índice adicional para la geometría del punto. Ejecute un trabajo cron regular que elimine las filas antiguas, ejecute el vacío / análisis y vuelva a agrupar.
- Particionar por fecha y hora y luego agrupar e indexar por elevación por tabla con un índice de geometría. Ejecute un trabajo cron regular para agregar nuevas tablas en el futuro y descartar las tablas antiguas.
Más lejos,
- Entonces, sé que dejar caer una tabla es mucho más eficiente y eliminar y aspirar. ¿Pero vería un aumento de rendimiento de lo contrario?
- ¿Son apropiadas las particiones cuando todas las tablas se actualizarán uniformemente y se seleccionarán hasta que se eliminen como irrelevantes (la documentación indica que las particiones funcionaron mejor cuando solo se seleccionaron algunas de ellas)?
Al entregar datos, ¿las selecciones serán más rápidas que el índice agrupado? ¿Cambia la respuesta si se realizan varias solicitudes a la vez?
Gracias. Espero haber puesto todos los datos necesarios. Si no, házmelo saber y lo agregaré.
xminoxmax, etc. Hay una característica que podría hacerlo en 9.4 que probablemente te excita, llamado índices MinMax, que hará que este tipo de cosas mucho más conveniente.Respuestas:
A fin de cuentas, iría con la opción 2. Las fechas se seleccionarán de manera uniforme, pero supongo que para una consulta determinada solo estarán involucradas una o dos particiones de fecha. Es una pena que no se pueda agrupar en geolocalización y partición en la fecha, lo que sería ideal. La elevación tiende a correlacionarse con la geolocalización de todos modos, si los cuadros delimitadores son lo suficientemente pequeños.
Dadas las opciones disponibles, es bueno tener operaciones de datos más limpias y evitar el vacío diario.
La entrega de selecciones puede ser más rápida con la opción 1, aunque sospecho que probablemente será un lavado. Con la opción 1, los registros con la misma fecha y elevación se colocan uno cerca del otro en un gran índice agrupado. Con la opción 2, los registros con la misma fecha y elevación se colocan uno cerca del otro en muchos índices agrupados más pequeños.
fuente