Como lidar com consultas de mais de 500 milhões de itens

A estrutura dos meus dados é a seguinte:

date: <timestamp>
filter_a: <integer> -> range [0, 1000]
filter_b: <integer> -> range [0, 1000]
filter_c: <integer> -> range [0, 86400]
filter_d: <integer> -> range [0, 6]
group: <string>
second_group: <integer>
variable_a: <float>
variable_b: <float>
variable_c: <float>
a couple more no very important

Preciso executar as seguintes consultas:

Primeiro:

• Filtrar dados date, filter_a, filter_b, filter_ce outros

Segundo, com os dados filtrados:

• conte todos os registros
• obter média de variable_a, variable_bevariable_c
• obter desvio padrão de variable_a, variable_bevariable_c
• obter quartis de variable_a, variable_bevariable_c
• agrupar dados por groupou second_groupagregados (Contagem, Média, Padrão, ..)

O número de usuários do sistema é cerca de 10 ou 15, mas o número de itens é enorme, agora é 70M mas será 500M em um par de semanas e será 1000M em cerca de um ano.

O número de consultas é pequeno, não mais que 10 usuários simultaneamente, meu problema é como lidar com essas consultas com essa enorme quantidade de dados.

O que eu tentei até agora?

• Comecei com mongodb, no início, era rápido, mas ficou lento ao calcular quartis com 10M +. Melhorou quando adicionei índices, mas não ajudou muito quando tive que consultar todos os dados. Comecei a usar o mongodb porque os dados eram muito dinâmicos, mas felizmente o formato dos dados "não muda mais".

• Como filter_ae filter_bpoderia ser visto como nós, tentei neo4j. Eu gostei muito do neo4j, mas meu gráfico tinha muitas arestas para que as consultas não fossem muito rápidas.

• Finalmente, como o formato dos dados não vai mudar e é apenas uma coleção / tabela, portanto não precisa de junções no SQL, verifiquei o postgresql. Meus testes foram mais rápidos com o postgresql, mas estou com medo de que não possa ser dimensionado adequadamente no futuro.

O que eu preciso?

• O postgresql é uma boa escolha para este caso?
• Existe outro tipo de banco de dados que eu poderia usar? qual é o melhor para este caso?
• O que mais eu poderia fazer para melhorar isso?

Editar

• Cerca de 1 milhão de elementos são inseridos todos os dias e "não devem mudar" ao longo do tempo.
• Velocidade de gravação não é importante
• O requisito difícil é ler / agregar rapidamente

Obrigado!

Em vez de recorrer a um banco de dados relacional para executar esses cálculos estatísticos em dados de séries temporais, sugiro que você mova esse trabalho de matemática e pós-processamento para fora do banco de dados em um aplicativo cliente.

Usando uma linguagem de script como Python ou Ruby, você pode resolver o problema de maneira incremental consultando "blocos" de dados por um período de largura fixa, calculando um resumo estatístico intermediário e combinando os resultados em vários blocos, conforme você executa o loop ao longo de toda a história. É difícil combinar algumas medidas estatísticas entre os pedaços, mas algo como Avg () só precisa de soma () e contagem () por pedaço, O (1) vs. O (tamanho do pedaço), portanto, a mesclagem de pedaços pode ser bem dimensionada.

Como seus dados não mudam e são apenas anexados, eu os armazenaria onde você quiser; Amazon S3, por exemplo, mas qualquer banco de dados de leitura rápida estará ok. Sem índices. O banco de dados / FS escolhido deve ter a opção de ler os dados nos buckets: você pode ter, por exemplo, um arquivo por dia com seus registros de 1 milhão.

Então eu usaria o Spark para fazer a filtragem / análise. É baseado em cluster, você pode dimensioná-lo de acordo com suas necessidades.

A resposta depende da maneira como você usará os dados depois disso. Se para processar melhor, use Cassandra, se para análise, use melhor o Hive.

Esse tipo de situação é ideal para data warehousing, usando as técnicas aperfeiçoadas por Ralph Kimball e companhia, em plataformas como o SQL Server (aquela com a qual estou mais familiarizado). Eles foram projetados especificamente com esse tipo de cenário em mente: grandes quantidades de registros de dados relativamente estáticos, para os quais você precisa calcular agregados desse tipo. Nãoa técnica relacional corresponderá ao armazenamento de dados implementado adequadamente em aplicativos desse tipo, embora alguns certamente sejam melhores que outros se sua organização simplesmente não puder pagar as licenças dos pacotes de software (como o SQL Server Analysis Services) que os implementam. Há também uma curva de aprendizado para implementar linguagens como MDX, feitas sob medida para esse tipo de acesso a dados. Se o armazenamento de dados for uma opção viável para sua organização, não perca tempo procurando uma solução relacional; este não é um problema de banco de dados relacional. Posso postar algumas referências básicas ao Kimball etc., e links para SSAS e MDX (desculpe, não posso ajudar com a Oracle e outros concorrentes com os quais não estou familiarizado), se necessário. Espero que ajude.