MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Y a-t-il des avantages à utiliser un _id personnalisé pour les documents dans MongoDB ?

Avantages de générer votre propre _id s :

  • Vous pouvez les rendre plus conviviales en leur attribuant des numéros incrémentiels :1 , 2 , 3 , ...

  • Ou vous pouvez les rendre plus conviviales, en utilisant des chaînes aléatoires :t3oSKd9q

    (Cela ne prend pas trop de place à l'écran, peut être sélectionné dans une liste et peut éventuellement être copié manuellement si nécessaire. Cependant, vous devez le faire suffisamment long pour éviter les collusions.)

  • Si vous utilisez des chaînes générées de manière aléatoire, elles auront une distribution de partitionnement à peu près égale, contrairement aux ObjectIds mongo standard, qui ont tendance à regrouper les enregistrements créés à peu près au même moment sur la même partition. (Que cela soit utile ou non dépend vraiment de votre stratégie de partitionnement.)

  • Ou vous pouvez générer votre propre _id personnalisé s qui regrouperont les objets associés sur un seul fragment, par ex. par propriétaire, ou région géographique, ou une combinaison. (Encore une fois, que cela soit souhaitable ou non dépend de la façon dont vous avez l'intention d'interroger les données et/ou de la rapidité avec laquelle vous les produisez et les stockez. Vous pouvez également le faire en spécifiant une clé de partition plutôt que le _id lui-même. Voir la discussion ci-dessous.)

Avantages de l'utilisation de ObjectId s :

  • Les ObjectIds sont très efficaces pour éviter les collisions. Si vous générez votre propre _id s de manière aléatoire ou simultanée, vous devez gérer vous-même le risque de collision.

  • Les ObjectIds contiennent leur heure de création. Cela peut être un moyen simple et peu coûteux de conserver la date de création d'un document et de trier les documents par ordre chronologique. (D'un autre côté, si vous ne voulez pas exposer/divulguer la date de création d'un document, alors vous ne devez pas exposer son ObjectId !)

Le nanoïde module peut vous aider à générer de courts identifiants aléatoires. Ils fournissent également un calculateur qui peut vous aider à choisir une bonne longueur d'identifiant, en fonction du nombre de documents/identifiants que vous générez chaque heure.

Alternativement, j'ai écrit mongoose-generate-unique-key pour générer très ID aléatoires courts (à condition que vous utilisiez la bibliothèque mongoose).

Stratégies de partage

Je ne prétendrai pas être un expert sur la meilleure façon de partager des données, mais voici quelques situations que nous pourrions envisager :

  1. Un observatoire astronomique ou un accélérateur de particules traite des gigaoctets de données par seconde. Lorsqu'un événement intéressant est détecté, ils peuvent vouloir stocker une énorme quantité de données en quelques secondes seulement. Dans ce cas, ils souhaitent probablement une répartition uniforme des documents sur les fragments, de sorte que chaque fragment travaille également dur pour stocker les données et qu'aucun fragment ne soit submergé.

  2. Vous avez une énorme quantité de données et vous avez parfois besoin de toutes les traiter immediatement. Dans ce cas (mais en fonction de l'algorithme), une distribution uniforme peut à nouveau être souhaitable, de sorte que tous les fragments puissent travailler de manière égale sur le traitement de leur bloc de données, avant de combiner les résultats à la fin. (Bien que dans ce scénario, nous puissions compter sur l'équilibreur de MongoDB, plutôt que sur notre clé de partition, pour la distribution égale. L'équilibreur s'exécute en arrière-plan après le stockage des données. Après avoir collecté beaucoup de données, vous devrez peut-être laissez-le redistribuer les morceaux pendant la nuit.)

  3. Vous avez une application de médias sociaux avec une grande quantité de données, mais cette fois de nombreux utilisateurs différents font de nombreuses requêtes légères liés principalement à leurs propres données, ou à leurs amis ou sujets spécifiques. Dans ce cas, cela n'a pas de sens d'impliquer chaque partition chaque fois qu'un utilisateur fait une petite requête. Il peut être judicieux de partitionner par userId (ou par sujet ou par région géographique) afin que tous les documents appartenant à un utilisateur soient stockés sur une seule partition, et lorsque cet utilisateur fait une requête, une seule partition doit fonctionner. Cela devrait laisser les autres partitions libres de traiter les requêtes d'autres utilisateurs, afin que plusieurs utilisateurs puissent être servis à la fois.

  4. Partage de documents par heure de création (que les ObjectIds par défaut vous donneront) peut être souhaitable si vous avez beaucoup de requêtes légères qui examinent des données pour des périodes similaires. Par exemple, de nombreux utilisateurs différents interrogeant différents graphiques historiques.

    Mais ce n'est peut-être pas si souhaitable si la plupart de vos utilisateurs n'interrogent que les documents les plus récents (une situation courante sur les plateformes de médias sociaux), car cela signifierait qu'un ou deux fragments obtiendraient l'essentiel du travail. La distribution par sujet ou peut-être par région peut fournir une distribution globale plus plate, tout en permettant également aux documents connexes de s'agglutiner sur une seule partition.

Vous aimerez peut-être lire les documents officiels à ce sujet :