Dans les discussions sur les bases de données NoSQL vs SQL, j'entends parfois que les entreprises préfèrent utiliser des bases de données NoSQL sans schéma, car il est problématique de migrer le schéma vers une nouvelle version. Mais est-ce vraiment un gros problème lors des mises à niveau? Les bases de données relationnelles sont-elles mauvaises pour de telles opérations?
J'ai lu cet article de blog sur le blog MongoDB: Pourquoi Schemaless?
Ce n'est pas parce que votre base de données NoSql n'a pas de schéma au sens traditionnel qu'il n'y a pas de schéma logique à gérer à mesure qu'il change. Dans le cas d'une application typique utilisant MongoDb, votre code s'attend très probablement à ce que certains champs de l'objet json se comportent de certaines manières. Si vous modifiez le comportement, il s'ensuit que vous souhaiterez peut-être mettre à jour les données déjà existantes dans la base de données. Maintenant, avec le SGBDR traditionnel, c'était un problème largement résolu - il suffisait de MODIFIER les tables sous-jacentes. Mais avec ces nouvelles bases de données NoSQL, vous avez une décision - écrivez-vous un script pour munger et mettre à jour tous vos objets? Ou ajoutez-vous du code pour convertir entre les versions à la volée? Si oui, combien de temps prenez-vous en charge les objets v1? Pour toujours? Jusqu'à la v3?
J'ajouterai que l'exemple utilisé dans le billet de blog MongoDb est un peu simpliste et un cas très facile à gérer si vous avez un processus de mise à jour décent quel que soit le SGBDR; l'ajout d'un champ fait rarement mal. C'est lorsque vous décidez de diviser votre Namedomaine FirstNameet LastNameque les choses deviennent passionnantes.
Ça peut être.
Certaines organisations sont - bien - désorganisées et font un très mauvais travail de migration de schéma.
"Week-end de migration". Arrêtez les serveurs. Sauvegardez et exportez toutes les données. Créez le nouveau schéma (souvent en modifiant le schéma existant). Recharger les données ou tenter de restructurer en place.
"Peaufinage continu". Modifiez les tables dans la mesure autorisée par SQL. Sans suivre la séquence d'ALTER effectuée. Sans aucun moyen de revenir à une version précédente du schéma. Si nécessaire, créez de nouvelles tables à partir des tables existantes, en ajustant, espérons-le, toutes les applications pour utiliser les nouvelles tables. Mais - manquant de bonne assurance qualité - laissant les anciennes tables en place "au cas où".
"Panique totale". Empêchez simplement les modifications de schéma. Faites une grosse puanteur. Affirmez que le risque est trop élevé. Bloquez tous les efforts dans cette direction. Prenez le schéma en otage jusqu'à ce qu'il soit forcé d'adopter une approche plus sensée.
Tout schéma est pénible à migrer.
Le plus gros problème n'est pas technique.
C'est sémantique.
L'une des principales raisons d'un changement de schéma est que le schéma précédent ne correspond pas très bien au domaine problématique. Comme la sémantique a changé, la base de données (et les applications) doivent changer. Parfois, ce sont des changements profonds qui nécessitent de repenser la façon dont les applications fonctionnent avec les données.
La révision de la sémantique de la base de données peut être très difficile.
Ce que les gens font au lieu de modifier le schéma, c'est simplement de mal utiliser le schéma physique. Ils commencent à charger des données erronées dans des champs existants car ils le peuvent. Un champ "commentaire" commence soudainement à avoir une information importante sur la gestion des clients suivie de "//" suivi du vrai commentaire. Cela se développe pour avoir des morceaux de données "champ 1 - champ 2 // commentaire". Les utilisateurs ont une feuille de calcul qui extrait ces données supplémentaires du champ de commentaire car le "vrai" logiciel d'application avait un schéma trop difficile à changer que le service informatique a refusé de le changer.
la source
Nous mettons à niveau les bases de données de production en ajoutant des tables et des colonnes (nullables) sans problème. Les versions précédentes de l'application fonctionnent bien avec la base de données mise à niveau, elles ne font tout simplement pas référence aux nouveaux éléments. Nous évitons de supprimer des tables ou des colonnes, ou de modifier la façon dont les données existantes sont stockées, bien que lorsque cela est nécessaire, nous produisons des scripts de conversion appropriés. Que votre base de données ait un schéma sécurisé de type déclaré ou non, les changements dans la structure des données nécessitent une conversion des données et des mises à niveau d'application pour interagir avec la nouvelle structure.
la source
Ça dépend.
Tout d'abord, si vous avez une très grande base de données couvrant plusieurs machines, alors tout (pas seulement la mise à jour de la base de données) va être pénible. (peu importe combien vous avez prévu à l'avance).
Deuxièmement, la mise à jour d'une base de données n'est PAS seulement une chose de base de données - cela dépend également du plus grand système dont la base de données fait partie. Cela inclut également le déploiement de la base de données (de nombreux serveurs de base de données, plusieurs centres de données, configurations maître-esclave, etc.)
La douleur peut être atténuée en architecturant vos composants système de telle sorte qu'ils aient tous une sorte de «connaissance» de l'événement de changement de schéma de base de données. Cela signifie que l'ensemble du système doit être tolérant aux changements de schéma et peut y répondre de manière «saine».
Vous pouvez consulter un utilitaire développé par Facebook pour gérer les mises à jour du schéma MySQL.
En outre, il existe des meilleures pratiques standard telles que la mise en lecture seule, la modification des esclaves ou la copie de développement, etc.
Dans tous les cas, avoir une sauvegarde complète et une suite de tests complète est un MUST. Ce n'est qu'alors que vous pourrez apporter des modifications en toute confiance et en toute sécurité.
la source