Almacenar y consultar datos continuos en PostgreSQL

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

— bshender
fuente

Ouch, estas filas estrechas son donde los encabezados de filas grandes de PostgreSQL comienzan a doler realmente. Lástima que no hay mucho que se pueda quitar; no es que podemos perder xmino xmax, 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.

— Craig Ringer

Es la siguiente combinación repetitiva: "latitud, longitud, geometría del punto, elevación". En caso afirmativo, normalizarlo en otra tabla puede ahorrar algo de espacio.

— AK

Solo marginalmente. Una geometría PostGIS es una matriz binaria y no legible por humanos. Podía derivar esos valores en la salida, pero luego no podía agruparlos. Podría usar un GeoHash para agrupar, pero eso ya no es más legible de lo que sería el lat lon. Pero de cualquier manera el espacio no es el problema. Ofrecieron tantos terrabytes como puedo llenar. El problema es que no puedo consultar terrabytes a gran velocidad. La base de datos en sí misma será en gran medida no transaccional. Solo dos scripts tendrán acceso de escritura. Todo lo demás es estrictamente de solo lectura.

— bshender

Craig: Parecen intrigantes. Espero experimentar con ellos cuando salgan. ¿Alguna idea sobre mi configuración en 9.3?

— bshender

¿Podría proporcionar dos piezas de información, por favor: 1) ¿Qué es lo más importante para usted, la velocidad de inserción o la velocidad de consulta? 2) ¿Qué consultas son las más comunes?

— Thomas Kejser

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.

— Carlos Bueno
fuente