MongoDB: Aleatório vs desempenho de leitura sequencial

Question

Eu tenho um mongodb de instância única com uma coleção com 3 campos: _id, block_id, payload.

• Os payloads são sempre binários de 4096 bytes
• _id é um inteiro exclusivo incrementado

Existe um índice secundário na coleção:

{ "v" : 1, "key" : { "block_id" : 1, "_id" : -1 }, 
  "ns" : "testdb.testdev", "name" : "_block_id_id" }

Estou fazendo muitas consultas como:

query: { query: { block_id: 868413 }, orderby: { _id: -1 } } ntoreturn:1 nscanned:1 nreturned:1 reslen:4166 163ms

Não há outra consulta durante estes. Quando eu leio sequencialmente por block_id, é 10 vezes mais rápido do que quando eu consultar com block_id aleatório. Eu tenho baixo uso de CPU, baixa utilização de armazenamento. A coleção é 2-3 vezes maior que o tamanho da memória.

Qual pode ser o gargalo aqui?

    

Answer 1

Algumas coisas para esclarecer aqui:

1. Você verá apenas as consultas lentas registradas por padrão (> 100ms), você poderá ter milhões de consultas executadas nesse limite que nunca será registrado
2. A maneira de descobrir qual é a causa das operações lentas é observar as estatísticas quando as operações lentas estão sendo registradas
3. Você deve executar novamente as consultas com .explain () para verificar se eles estão usando o índice que você acho que eles são

Em termos de estatísticas, existem duas maneiras básicas de obtê-las. Primeiro, e mais rápido, é mongostat e mongotop . Esses dois utilitários são fornecidos com o MongoDB e podem ser usados para descobrir o que seu banco de dados está fazendo.

A outra opção é MMS (o Serviço de Monitoramento do MongoDB) - é gratuito e permite representar graficamente todas as estatísticas relevantes ao longo do tempo, para que você possa determinar o que é spiking / dipping quando você vê lentidão. Eu recomendo instalar o munin-node se você seguir esse caminho (veja MMS docs) porque ele lhe dará uma visão das estatísticas de IO, assim como as estatísticas do MongoDB.

Normalmente, você está procurando um dos itens a seguir:

1. Falhas de página - se isso estiver aumentando, suas consultas estão causando paginação em disco - isso é uma ordem de magnitude mais lenta que as operações na memória e precisa ser minimizada.
2. Memória residente - intimamente relacionada a falhas de página, isso representa seu conjunto de trabalho na memória. Você menciona que seu conjunto de dados tem de 2 a 3 vezes o tamanho da RAM, mas você incluiu índices nessa estimativa (consulte o

Há muitas outras coisas para analisar, mas é um bom começo, dada a sua descrição. Lembre-se, se você tiver contenção de memória, o mais novo é mais provável que já esteja na memória. Como você está usando um ID seqüencial, eu esperaria que os IDs antigos (a menos que atualizados ou tocados recentemente) apareçam no log de consultas lentas com mais frequência do que os novos IDs (é assim que o sistema operacional geralmente gerencia a memória - consulte LRU para mais).

Em termos de lidar com esse tipo de problema de desempenho, além de adicionar mais RAM, você deve analisar:

1. Removendo índices desnecessários que podem ocupar espaço
2. Veja as consultas índice coberto , se possível ( não há necessidade de página nos dados, apenas o índice)
3. Verifique suas configurações de leitura antecipada - um tópico longo e complexo - consulte aqui e aqui para mais informações (e mais informações em geral)