Bear Bile Farming is Torture's questions

esquema:

{
  time_utc: "milliseconds",
  city: "string",
  age: "integer"
}

índice:

{
  time_utc: 1,
  city: 1,
  age: 1
}

consulta de exemplo:

col.aggregate([
  {
    $match: { time_utc: { $exists: true }  city: "new york", age: { $gt: 18 } }
  },
  {
    $sort: { time_utc: -1 }
  }
])

Tenho certeza que o índice composto será utilizado nesta consulta, para que a classificação seja eficiente.

No entanto, a $matchetapa /filtragem de documentos não parece eficiente porque podemos assumir que time_utcé única em toda a coleção.

Suponhamos que haja 1 milhão de documentos no acervo e apenas 10 serão devolvidos. Suponhamos ainda que os 10 documentos estejam localizados na parte inferior da time_utcclassificação.

Neste cenário, a consulta deve varrer todo o valor de 1 milhão do índice para descobrir os 10 documentos. Isso equivale a uma varredura completa da coleção.

Vamos supor o contrário, que existam apenas 2 valores únicos em time_utc. Neste cenário, parece que o índice para os campos citye agepode de fato ser eficaz.

Meu raciocínio está correto?

Suponhamos que existam 100 tipos de cães espalhados pelos documentos da minha coleção. Se eu preciso agrupar por tipos de cães e depois calcular algumas estatísticas agregadas sobre cada tipo de cão, por que realizar uma consulta envolvendo , $groupque em princípio processa cada documento sequencialmente, em vez de enviar 100 consultas separadas e simultâneas ao banco de dados onde cada consulta é filtrada com base sobre o tipo de cachorro?

As 100 consultas simultâneas e separadas não seriam mais rápidas?

Se for mais rápido, em escala, qual é a desvantagem de não fazê-lo, se houver?

Na coleção A, cada documento contém até 100 campos. O banco de dados, mongoDB, permite apenas até 64 índices em uma única coleção.

Os índices são necessários para uma consulta nesta coleção. A etapa filtro, ou $match, desta consulta pode ser feita utilizando qualquer combinação dos 100 campos.

Mesmo que sejam criados 64 índices, ele poderá cobrir no máximo 64 campos.

Problema:

Isso significa que, se a consulta for filtrada com base em qualquer um dos 36 campos não indexados, uma varredura de coleta deverá ser feita para concluir a consulta.

Pergunta:

Existem formas alternativas de otimizar essa consulta, impedindo uma varredura de coleção em todas as combinações possíveis dessa consulta?

Entendo que uma coleção pode ser fragmentada em um cluster. Isso significa que cada fragmento tem a garantia de viver em seu próprio servidor de hardware? Ou vários fragmentos podem compartilhar o mesmo hardware?

Se vários fragmentos residirem no mesmo hardware, isso não prejudicaria o objetivo da simultaneidade no desempenho da consulta?