- Temos uma única tabela onde armazenamos Events .
- A tabela tem um índice em sua chave primária
Assumindo que estamos apenas fazendo SELECTs ou s simples INSERTnessa tabela - o tempo de recuperação ou inserção ficaria visivelmente* mais lento à medida que mais e mais linhas fossem adicionadas?
Meu entendimento (muito grosseiro) é que um índice torna o tempo de pesquisa não linear (não-O(N)), portanto, pelo menos teoricamente, não será um problema - mas gostaria de confirmar isso.
Estamos trabalhando com o PostgreSQL 9.5.3 e em algum momento esperamos que essa tabela tenha bilhões de linhas.
*perceptível: leva < 1 segundo para recuperar 5.000 eventos agora, perceptível seria > 2 segundos
As mesas não desaceleram ou aceleram, elas apenas ficam lá. As declarações, por outro lado, podem desacelerar. Você não fornece detalhes suficientes sobre seus dados, mas se sua chave primária estiver aumentando monotonicamente, como um carimbo de data/hora ou um valor de sequência, você acabará reequilibrando sua árvore com bastante frequência nas inserções. Ao mesmo tempo, com essa chave primária, você pode criar um ponto de acesso de simultaneidade no final, onde todas as inserções acontecerão.
Enquanto isso, aumentar de 10 6 para 10 9 entradas no índice leva você de 20 comparações para 30 para a pesquisa de pior caso, o que representa um aumento de 50%, portanto, dependendo do tamanho do valor de PK, é totalmente viável que você exceda seu limite de visibilidade de 2 segundos com alguns "bilhões" de linhas na tabela.
A velocidade nas instruções de seleção ou inserção de tabela depende de muitos fatores:
Todas essas coisas podem afetar suas consultas. Seu índice ajuda a aumentar a velocidade em certas declarações (aquelas que podem usar os dados no índice sem precisar pesquisar a tabela inteira). O índice em si não é uma coisa ruim.
Agora, a velocidade muda: em condições normais de operação, você não deve ver mudanças apreciáveis na velocidade da consulta. (normal = dia médio de trabalho, anormal = dia quando você tem uma grande carga ou exclusão de dados, quando outro banco de dados é criado nessa caixa e está em produção, a energia acaba e você está funcionando com bateria.) Dito isso, dependendo de quantos usuários simultâneos você tem, uma diferença de 1 segundo em uma consulta pode ser normal.
Aqui está o que procuro se suspeitar de problemas de desempenho do banco de dados: 1. Alguma alteração recente no banco de dados ou no servidor? 2. A consulta em execução é substancialmente diferente do normal? Uma consulta com 4 junções não será tão eficiente quanto uma consulta em 1 tabela sem junções. 3. Algum problema ambiental ultimamente? Como energia, reinicializações inesperadas. 4. Revise os logs do banco de dados e procure por erros, bloqueios e similares. 5. Revise os logs do servidor e procure por erros. 6. Algum problema de rede ultimamente? Verifique com o grupo de rede em seus logs. 7. Faça uma consulta de teste que seja sua linha de base. Você executa isso no início da vida do banco de dados, observe o tempo de execução e o número de linhas retornadas. Então, quando você suspeitar que as coisas não estão funcionando bem, execute sua consulta de teste novamente. Há uma mudança substancial em relação à sua linha de base? Linhas adicionais e algum aumento no tempo são esperados. Dados muito diferentes, bloqueio de tabela na consulta ou uma desaceleração de 10 vezes em relação à sua última execução de teste seriam incomuns. Se sim, investigue o porquê.
Tente algumas ou todas essas etapas e veja se descobre algum problema.