Discordo totalmente do autor da resposta selecionada que Não há id de incremento automático no MongoDB e há boas razões . Não sabemos os motivos pelos quais a 10gen não incentivou o uso de IDs incrementados automaticamente. É especulação. Acho que a 10gen fez essa escolha porque é mais fácil garantir a exclusividade de IDs de 12 bytes no ambiente em cluster. É a solução padrão que se adapta à maioria dos recém-chegados, portanto, aumenta a adoção do produto, o que é bom para os negócios da 10gen.
Agora deixe-me contar a todos sobre minha experiência com ObjectIds em ambiente comercial.
Estou construindo rede social. Temos cerca de 6 milhões de usuários e cada usuário tem cerca de 20 amigos.
Agora imagine que temos uma coleção que armazena relacionamento entre usuários (quem segue quem). Se parece com isso
_id : ObjectId
user_id : ObjectId
followee_id : ObjectId
no qual temos um índice composto exclusivo
{user_id, followee_id} . Podemos estimar o tamanho desse índice como 12*2*6M*20 =2GB. Agora esse é o índice para pesquisa rápida de pessoas que sigo. Para pesquisa rápida de pessoas que me seguem, preciso de índice reverso. São mais 2 GB. E isso é apenas o começo. Eu tenho que carregar essas identificações em todos os lugares. Temos um cluster de atividades onde armazenamos seu Feed de Notícias. Isso é cada evento que você ou seus amigos fazem. Imagine quanto espaço é necessário.
E finalmente um de nossos engenheiros tomou uma decisão inconsciente e decidiu armazenar referências como strings que representam ObjectId que dobra seu tamanho.
O que acontece se um índice não couber na RAM? Nada de bom, diz 10gen:
Quando um índice é muito grande para caber na RAM, o MongoDB deve ler o índice do disco, o que é uma operação muito mais lenta do que a leitura da RAM. Lembre-se de que um índice se encaixa na RAM quando seu servidor tem RAM disponível para o índice combinado com o restante do conjunto de trabalho.
Isso significa que as leituras são lentas. A contenção de bloqueio aumenta. As gravações também ficam mais lentas. Ver a contenção de bloqueio em 80% de acabamento não é mais um choque para mim.
Antes que você perceba, você acabou com um cluster de 460 GB que você precisa dividir em fragmentos e que é bastante difícil de manipular.
O Facebook usa 64 bits como ID de usuário :) Há uma razão para isso. Você pode gerar IDs sequenciais
- usando conselho do 10gen .
- usando mysql como armazenamento de contadores (se você está preocupado com a velocidade, dê uma olhada em handlersocket )
- usando o serviço de geração de ID que você criou ou usando algo como Snowflake pelo Twitter.
Então aqui está meu conselho geral para todos. Por favor, faça seus dados tão pequenos quanto possível. Quando você crescer, você economizará muitas noites sem dormir.
