Désavantage de performances en utilisant slug comme clé primaire/_id dans mongo ?

A mon avis, non. La différence de performances sera négligeable pour la plupart des scénarios (sauf la pagination ), mais

• La vieille discussion sur les clés primaires de substitution revient. Un "slug" n'est pas une clé très naturelle. Oui, il doit être unique, mais comme vous l'avez déjà souligné, changer le slug ne devrait pas être impossible. Cela seul m'éviterait de déranger...
• Avoir un _id monotone la clé peut vous éviter un certain nombre de maux de tête, surtout pour éviter une pagination coûteuse via skip et take (utilisez $lt /$gt sur le _id à la place).
• Il y a une limite sur la longueur d'index maximale dans mongodb de moins que 1024 octets. Bien que ce ne soit pas joli, les URL sont autorisées à être beaucoup plus longtemps . Si quelqu'un saisit un slug plus long, il ne sera pas trouvé car il est supprimé silencieusement de l'index.
• C'est une bonne idée d'avoir une interface cohérente, c'est-à-dire d'utiliser le même type de _id sur tous, ou du moins, la plupart de vos objets. Dans mon code, j'ai une seule exception où j'utilise un hachage spécial comme identifiant car la valeur ne peut pas changer, la collection a des taux d'écriture extrêmement élevés et elle est volumineuse.
• Supposons que vous souhaitiez créer un lien vers l'article dans votre interface de gestion (et non sur le site public), quel lien utiliseriez-vous ? Normalement l'id, mais maintenant l'id et le slug sont équivalents. Maintenant, un simple bogue (comme autoriser un slug vide) serait difficile à récupérer, car l'utilisateur ne pourrait même plus accéder à l'interface de gestion.
• Vous serez confronté à des problèmes de jeu de caractères. Je suggérerais même de ne pas utiliser le slug pour rechercher l'article, mais le hachage du slug .

Essentiellement, vous vous retrouveriez avec un schéma comme

{ "_id" : ObjectId("a237b45..."), // PK
  "slug" : "mongodb-is-fun", // not indexed
  "hash" : "5af87c62da34" } // indexed, unique