J'écris un moteur de base de données NOSQL et je souhaite fournir des fonctionnalités pour aider les développeurs à mettre à niveau leur application vers une nouvelle version sans empêcher le fonctionnement du site Web, c'est-à-dire à 0% de temps d'arrêt lors de la mise à niveau. Ma question est donc, quelles sont les méthodes ou la conception générale d'une application Web lorsqu'elle est exécutée 24/7 et modifie très souvent sa structure de base de données? Tous les exemples ou histoires de réussite seraient grandement appréciés.
6 Réponses :
La structure de la base de données est étroitement liée aux règles commerciales. Le seul scénario que je puisse penser dans lequel la base de données change est souvent dans la phase de développement d'un projet.
Dans un environnement de production, il est supposé que la demande est déjà stable en termes de règles commerciales, de sorte que les modifications apportées à la structure de la base de données sont supposées être rares. Par conséquent, je pense qu'il sera très difficile de trouver des solutions élaborées pour ce cas.
Il y a bien sûr des approches naïves telles que la copie exacte de la base de données avant la mise à niveau, la commutation de l'application pour exécuter sur la copie, la mise à niveau, puis la mise en marche.
Autre que cela, je ne peux penser à rien d'autre.
Disons par exemple, le téléphone portable devient obsolète et personne ne l'utilise plus, nous communiquons plutôt par la pensée. Facebook a maintenant besoin de supprimer le numéro de téléphone mobile et d'ajouter un nouveau champ appelé «Digest de la pensée» qui vous permettra de communiquer des pensées cryptées. Comment mettez-vous à niveau Facebook en quelques secondes de 1 million de demandes par seconde? Les choses à propos de prod et de dev les environnements que nous connaissons déjà
Facebook est un système distribué. C'est une autre chose complètement.
Plus votre scénario n'est pas "Changer de structure de base de données très souvent"
avec NOSQL - et spécifiquement une base de données orientée de documents - vous pouvez y accomplir avec des versions.
considère que mongodb, qui stocke tout comme documents.
MongoDB vous permet d'avoir une collection (un groupe de documents) où le schéma de chaque document peut être différent.
Disons que vous avez ce document pour un utilisateur:
Vous pouvez également avoir ceci comme document dans la même collection:
Schemas différents, mais tous les deux dans la même collection. Évidemment, cela est très différent d'une base de données relationnelle traditionnelle.
La solution est ensuite d'ajouter un champ à chaque document qui a la version de schéma. Ensuite, vous avez la recherche de votre application pour cette version avec chaque requête.
Une requête de Mongodb pourrait ressembler à ceci:
qui vient de retourner tous les utilisateurs utilisant la version de schéma "3". Vous pouvez insérer des schémas plus récents sans affecter le site existant et supprimer lentement les anciennes versions de schéma qui ne sont plus utiles.
{
"_ID": 100,
"Prénom": "John",
"Nom": "Smith"
}
{
"_ID": 123,
"Prénom": "John",
"Nom": "Smith",
"HASFOO": faux
}
utilisateurs.find ({"Version": 3}). Limite (10);
Vous allez être la construction d'un système distribué. Il n'y a pas moyen de contourner cela, comme vous aurez besoin de plusieurs machines impliquées pour faire face à des choses comme les redémarrages.
Construire un moyen de système distribué, vous faites des choix. Choisissez 2:
Des systèmes comme S3, ont choisi 1 & 2 et payé le prix en sacrifiant # 3 en faveur de « Consistance eventuel ». Il y a un grand papier sur S3 vous pouvez lire. D'autres solutions de bases de données, comme DynamoDB ont choisi différents compromis.
Vous allez équilibreurs besoin de charge. Sinon, vous êtes coincé avec les clients se connectant directement à votre service, ce qui est difficile pour diverses raisons. A Load Balancer vous permet de redémarrer une machine dans votre flotte sans encourir le temps d'arrêt. Redémarrages, comme nous le savons tous, sont un fait de la vie.
Faire ce que vous décrivez est très difficile. En fait, je dirais qu'il est presque un problème impossible pour un seul développeur pour faire face.
Vous êtes loin, loin, beaucoup plus de chances d'obtenir de meilleurs résultats en utilisant une base de données NoSQL existants et passer tout votre temps de travail sur votre produit ....
Si une entreprise peut investir dans la distribution géographique de la base de données. Comme la tolérance de basculement; Il semble que la réplication traditionnelle mais la réplication des données (ou la réplication de données de données de données) ne serait pas un problème de routage du trafic.
Option 2: - Utilisation de la mise en cache (Développement personnalisé) et du vélo. Ex: - 1 heure am à 2 sam Utilisez l'instantané 1 de la base de données (disons Server1 / Data Center 1) 1:59 AM Server2 / Data Center 2 est composé d'une nouvelle architecture de base de données (nouveaux champs, de nouvelles tables, etc., etc., et @ 2h de la route de la circulation via Data Center 2.
Cyclisme Basing L'instantané peut être une solution à considérer.
Lorsque de nombreux serveurs Web dans un environnement de production accèdent à cette base de données, et que vous avez un changement de code incompatible (qui supprime un champ et ajoute un nouveau champ), je conseillerais la solution multitons. C'est un peu de travail mais vous n'avez pas de temps à temps de RISC lorsque certains détails ne vont pas.
Première étape Étendez l'application afin que l'ancienne et la nouvelle version soit écrite, déployez cette version
deuxième étape convertit aussi loin que possible les anciennes valeurs de champ de données au nouveau champ de données (peuvent prendre un certain temps).
quatrième étape retirez les anciennes valeurs de champ
cinquième étape Supprimez l'écriture des valeurs de champ anciens à partir du code, déployez-la.
Le seul cas possible où cela peut être atteint, c'est si vous avez une application complètement apatride. Le terme apatride inclut à la fois la structure des données d'application et de l'application. N'oubliez pas que la mise à niveau peut impliquer de modifier la définition des objets métier en plus des données. Étant donné que cette application apatride n'est pas pratique en raison de raisons évidentes, il n'existe pas de moyen pratique d'atteindre un temps d'arrêt de zéro pour des mises à niveau générales. Toute application qui n'est pas apatride disposera de la mise en cache des utilisateurs en direct (dans les données commerciales de la biche). Une mise à niveau peut justifier non seulement les nouvelles données commerciales, mais également les nouvelles définitions d'objet métier. Les données mises en cache des utilisateurs vivants peuvent toujours causer des incohérences potentielles avec le nouveau schéma. Les utilisateurs vivants ne peuvent donc pas être migrés à moins que vous ne puissiez migrer à la fois les données et les métadonnées (définitions de l'entreprise) mis en cache dans le niveau médiocre. Si vous soufflez le cache de niveau moyen, les utilisateurs vivants seront affectés. Vous pouvez envisager de permettre aux utilisateurs vivants de continuer à travailler sous l'ancien DB et de migrer / fusionner les modifications de données sur la nouvelle DB ultérieurement. Mais c'est un problème compliqué à résoudre aussi bien. Maintenant, il est possible de limiter ce qui est autorisé sous une mise à niveau de temps d'arrêt de zéro sans affecter les utilisateurs en direct ou assurez-vous qu'après la mise à niveau de la base de données, les utilisateurs en direct deviennent simplement des utilisateurs en lecture seule, à moins qu'ils ne se déconnectent et se déconnectent contre le nouveau schéma.
Par intérêt, pourquoi écrivez-vous un moteur de base de données NOSQL? Aucun des éléments existants ne convient-il à vos besoins?
Gardez à l'esprit qu'il n'y a pas de mal à ajouter un champ uniquement à en prendre un ...
Toutes les bases de données sont lentes. J'écris un moteur très rapide qui fera une insertion dans environ 2 000 cycles d'horloge, ce qui représenterait environ 20 millions d'inserts par seconde sur un ordinateur portable moyen.