MongoDB
 sql >> Base de Dados >  >> NoSQL >> MongoDB

Existem vantagens em usar um _id personalizado para documentos no MongoDB?


Vantagens de gerar seu próprio _id s:

  • Você pode torná-los mais amigáveis, atribuindo números incrementais:1 , 2 , 3 , ...

  • Ou você pode torná-los mais amigáveis, usando strings aleatórias:t3oSKd9q

    (Isso não ocupa muito espaço na tela, pode ser escolhido em uma lista e pode ser copiado manualmente, se necessário. No entanto, você precisa torná-lo longo o suficiente para evitar conluios.)

  • Se você usar strings geradas aleatoriamente, elas terão uma distribuição de fragmentação aproximadamente uniforme, ao contrário do mongo ObjectIds padrão, que tende a agrupar registros criados na mesma época no mesmo fragmento. (Se isso é útil ou não depende muito da sua estratégia de fragmentação.)

  • Ou você pode gerar seu próprio _id personalizado s que agrupará objetos relacionados em um fragmento, por exemplo. por proprietário, ou região geográfica, ou uma combinação. (Novamente, se isso é desejável ou não depende de como você pretende consultar os dados e/ou com que rapidez você os está produzindo e armazenando. Você também pode fazer isso especificando uma chave de fragmentação, em vez do _id em si. Veja a discussão abaixo.)

Vantagens de usar ObjectId s:

  • ObjectIds são muito bons para evitar colisões. Se você gerar seu próprio _id s aleatoriamente ou simultaneamente, então você precisa gerenciar o risco de colisão por conta própria.

  • ObjectIds contêm seu tempo de criação dentro deles. Essa pode ser uma maneira barata e fácil de manter a data de criação de um documento e classificá-los cronologicamente. (Por outro lado, se você não deseja expor/vazar a data de criação de um documento, não deve expor seu ObjectId!)

O nanoid O módulo pode ajudá-lo a gerar IDs aleatórios curtos. Eles também fornecem uma calculadora o que pode ajudá-lo a escolher um bom tamanho de identificação, dependendo de quantos documentos/ids você está gerando a cada hora.

Como alternativa, escrevi mongoose-generate-unique-key por gerar muito IDs aleatórios curtos (desde que você esteja usando a biblioteca do mangusto).

Estratégias de fragmentação


Não pretendo ser um especialista sobre a melhor forma de fragmentar dados, mas aqui estão algumas situações que podemos considerar:

  1. Um observatório astronômico ou acelerador de partículas lida com gigabytes de dados por segundo. Quando um evento interessante é detectado, eles podem querer armazenar uma grande quantidade de dados em apenas alguns segundos. Nesse caso, eles provavelmente desejam uma distribuição uniforme de documentos entre os estilhaços, para que cada estilhaço trabalhe igualmente para armazenar os dados e nenhum estilhaço fique sobrecarregado.

  2. Você tem uma grande quantidade de dados e às vezes precisa processar todos eles de uma vez só. Nesse caso (mas dependendo do algoritmo), uma distribuição uniforme pode ser novamente desejável, para que todos os fragmentos possam trabalhar igualmente duro no processamento de seu pedaço de dados, antes de combinar os resultados no final. (Embora, neste cenário, possamos contar com o balanceador do MongoDB, em vez de nossa chave de fragmentação, para a distribuição uniforme. O balanceador é executado em segundo plano após o armazenamento dos dados. Após coletar muitos dados, talvez seja necessário deixe redistribuir os pedaços durante a noite.)

  3. Você tem um aplicativo de mídia social com uma grande quantidade de dados, mas desta vez muitos usuários diferentes estão fazendo muitas consultas leves relacionados principalmente aos seus próprios dados, ou seus amigos ou tópicos específicos. Nesse caso, não faz sentido envolver todos os shards sempre que um usuário fizer uma pequena consulta. Pode fazer sentido fragmentar por userId (ou por tópico ou por região geográfica) para que todos os documentos pertencentes a um usuário sejam armazenados em um fragmento e, quando esse usuário fizer uma consulta, apenas um fragmento precise funcionar. Isso deve deixar os outros fragmentos livres para processar consultas de outros usuários, para que muitos usuários possam ser atendidos de uma só vez.

  4. Fragmentação de documentos por hora de criação (que os ObjectIds padrão fornecerão) pode ser desejável se você tiver muitas consultas leves analisando dados por períodos de tempo semelhantes. Por exemplo, muitos usuários diferentes consultando diferentes gráficos históricos.

    Mas pode não ser tão desejável se a maioria de seus usuários estiver consultando apenas os documentos mais recentes (uma situação comum em plataformas de mídia social), porque isso significaria que um ou dois fragmentos estariam recebendo a maior parte do trabalho. Distribuir por tópico ou talvez por região pode fornecer uma distribuição geral mais plana, ao mesmo tempo em que permite que documentos relacionados se agrupem em um único fragmento.

Você pode gostar de ler os documentos oficiais sobre este assunto: