Je pense que c'est une très bonne question, mais les réponses vont être un peu dispersées en fonction des bibliothèques que vous utilisez et de vos attentes pour une "migration".
Examinons quelques actions de migration courantes :
- Ajouter un champ : Mongo rend cela très facile. Ajoutez simplement un champ et vous avez terminé.
- Supprimer un champ : En théorie, vous n'êtes pas réellement lié à votre schéma, donc la "suppression" ici est relative. Si vous supprimez la "propriété" et ne chargez plus le champ, cela n'a pas vraiment d'importance si ce champ est dans les données. Donc, si vous ne le faites pas souciez-vous de "nettoyer" la base de données, puis la suppression d'un champ n'affecte pas la base de données. Si vous faites vous souciez du nettoyage de la base de données, vous devrez essentiellement exécuter une boucle for géante sur la base de données.
- Modifier un nom de champ : C'est aussi un problème difficile. Lorsque vous renommez un champ "où", le renommez-vous ? Si vous voulez que la base de données reflète le nouveau nom de champ, vous devez essentiellement exécuter une boucle for géante sur la base de données. POUR être sûr, vous devez probablement "ajouter" des données, puis pousser du code, puis "désactiver" l'ancien champ.
Quelques rides
Cependant, le concept d'un nom de champ en tandem avec un objet ActiveRecord est juste un peu biaisé. Un objet ActiveRecord fournit effectivement des mappages de propriétés d'objet aux champs de base de données réels.
Dans un SGBDR typique, la "taille" d'un nom de champ n'est pas vraiment pertinente. Cependant, dans Mongo, le nom du champ occupe en fait l'espace de données, ce qui fait une grande différence en termes de performances.
Maintenant, si vous utilisez une forme "d'objet de données" comme ActiveRecord, pourquoi tenteriez-vous de stocker les noms de champs complets dans les données ? La base de données devrait probablement stocker tous les champs par ordre alphabétique avec une carte du côté objet. Ainsi, un document pourrait avoir 8 champs/propriétés et les noms de base de données seraient "a", "b"..."j", mais les noms d'objet seraient lisibles comme "Nom", "Prix", "Quantité".
La raison pour laquelle j'en parle est qu'il ajoute encore une autre ride à Modifier un nom de champ . Si vous implémentez un mappage, la modification d'un nom de champ ne provoque pas vraiment de migration.
Encore plus de rides
Si vous faites souhaitez implémenter une migration sur une suppression, vous devrez le faire après un déploiement. Vous devrez également reconnaître que vous n'économiserez pas d'espace disque actuel lorsque vous le ferez.
Mongo pré-alloue de l'espace et il ne le "rend pas" vraiment à moins que vous ne répariez la base de données. Ainsi, si vous supprimez un ensemble de champs sur des documents, ces documents occupent toujours le même espace sur le disque. Si les documents sont déplacés ultérieurement, vous pouvez récupérer de l'espace, mais les documents ne sont déplacés que lorsqu'ils grandissent.
Si vous supprimez un grand champ de nombreux documents, vous souhaiterez effectuer une réparation ou vérifier le nouveau compact
commande.
