Armazenando e consultando dados contínuos no PostgreSQL

Eu tenho uma grande quantidade de dados de modelos climáticos sendo colocados em um banco de dados PostgreSQL. A máquina possui 8 núcleos e 16 GB de RAM. Estou executando o PostgreSQL 9.3 com o PostGIS 2.1. Cada tabela terá uma variedade diferente de dados climáticos (temperatura, ponto de orvalho, vento, etc.). Cada tabela terá de 6 a 7 colunas: latitude, longitude, geometria do ponto, elevação, data e hora em que o modelo é relevante e 1-2 valores de dados de interesse. Os dados serão consultados principalmente para uma caixa delimitadora por tempo e elevação. Haverá aproximadamente 145.757.360 linhas por tabela (os dados mais antigos do que agora não são mais relevantes serão excluídos). Estimo aproximadamente o tamanho das tabelas em cerca de 10 GB cada, sem índices. (São 52 bytes de dados mais 23 bytes de sobrecarga por linha). Os dados serão atualizados / inseridos regularmente à medida que novos dados do modelo estiverem disponíveis. Nota:

Então, eu estou olhando para esses dois planos:

Simplesmente indexe e agrupe por (data e hora, elevação) com um índice adicional para a geometria do ponto. Execute um trabalho cron regular que exclua linhas antigas, execute vácuo / analise e re-agrupe.
Particione por data e hora e, em seguida, agrupe e indexe por elevação por tabela com um índice na geometria. Execute um trabalho cron regular para adicionar novas tabelas daqui para frente e descarte tabelas antigas.

Mais distante,

Então, eu sei que largar uma mesa é muito mais eficiente e excluir e aspirar. Mas eu veria um aumento no desempenho caso contrário?
As partições são apropriadas quando todas as tabelas serão atualizadas uniformemente e selecionadas até serem excluídas como irrelevantes (a documentação indicava que as partições funcionavam melhor quando apenas algumas delas seriam selecionadas)?

Ao entregar dados, as seleções serão mais rápidas que o índice em cluster? A resposta muda se várias solicitações estão sendo feitas ao mesmo tempo?

Obrigado. Espero colocar todos os dados necessários. Se não, deixe-me saber e vou adicioná-lo.

— bshender
fonte

Ai, essas linhas estreitas são onde os cabeçalhos de linhas grandes do PostgreSQL começam a realmente doer. Pena que não há muito que possa ser removido; não é como podemos perder xminou xmax, etc. Há um recurso que pode chegar à 9.4 que provavelmente o excitará, chamado índices minmax, que tornará coisas assim muito mais convenientes.

— Craig Ringer

É a seguinte combinação repetitiva: "latitude, longitude, geometria do ponto, elevação". Se sim, normalizá-lo em outra tabela pode economizar um pouco de espaço.

— AK

Apenas marginalmente. Uma geometria PostGIS é uma matriz binária e não legível por humanos. Eu poderia derivar esses valores na saída, mas não poderia agrupá-los. Eu poderia usar um GeoHash para agrupar, mas isso não é mais legível do que o futuro seria. Mas de qualquer maneira o espaço não é o problema. Eles ofereceram tantos terrabytes quanto eu posso preencher. O problema é que não consigo consultar terrabytes em alta velocidade. O próprio banco de dados será amplamente não transacional. Apenas dois scripts terão acesso de gravação. Todo o resto é estritamente somente leitura.

— precisa saber é

Craig: Eles parecem intrigantes. Espero experimentar com eles quando forem lançados. Quaisquer pensamentos sobre a minha instalação na versão 9.3?

— precisa saber é

Você poderia fornecer duas informações: 1) O que é mais importante para você, inserir velocidade ou velocidade de consulta? 2) Quais consultas são as mais comuns?

— Thomas Kejser 27/10/2014

Considerando tudo, eu usaria a opção 2. As datas serão selecionadas igualmente, mas vou supor que, para uma determinada consulta, apenas uma ou duas partições de data estejam envolvidas. É uma pena que você não possa agrupar na geolocalização e particionar na data, o que seria ideal. A elevação tende a se correlacionar com a localização geográfica de qualquer maneira, se as caixas delimitadoras forem suficientemente pequenas.

Dadas as opções disponíveis, operações de dados mais limpas e evitar o vácuo diário é uma boa coisa a ter.

A entrega de seleções pode ser mais rápida com a opção 1, embora eu suspeite que provavelmente seja uma lavagem. Com a opção 1, registros com a mesma data e elevação são colocados próximos um do outro em um grande índice clusterizado. Com a opção 2, registros com a mesma data e elevação são colocados próximos uns dos outros em muitos índices agrupados menores.

— Carlos Bueno
fonte