IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Migration SGBD Discussion :

Migration progressive !


Sujet :

Migration SGBD

  1. #1
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Décembre 2006
    Messages
    81
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Décembre 2006
    Messages : 81
    Points : 56
    Points
    56
    Par défaut Migration progressive !
    Bonjour à tous !

    Je travaille depuis peu dans une societe e-commerce. L'ensemble du site est developpé en php4 procédural, rien de documenté, une base ameliorable, etc. Mon futur projet dans cette société est de leur developper une site "optimisé mobile".

    Je vais developper le site entièrement avec symfony 2 et jquery mobile, et j'aimerais également reprendre entièrement la conception de la base, aprés avoir pris soin de detailler dans de beaux diagrammes UML, tous les cas d'utilisations de l'application... Le but sera ensuite basculer le site internet lui meme sur symfony2 et la nouvelle base propre aprés avoir implémenté toutes les fonctionnalités...

    Je voulais simplement savoir si je pouvais, a travers une solution open source (ca serait l'ideal), avoir 2 bases distinctes, différentes par leurs schéma, leur encodage, leur moteur, etc. Contenant au final les meme donnees et surtout, synchronisées entre elles, avec gestions des conflits de synchro, et tout ce qu'il faut pour que ça groove ;-)

    Je sais pas si je divague complètement ou si il existe des outils pour répondre a cette problématique, mais si c'est le cas, ca nous donnerait la souplesse de pouvoir continuer a travailler sur le nouveau site (d'abord mobile, puis le site lui meme) en parrallele avec la version existante avec des bases toujours a jour sur les 3 systèmes.

    J'ai vu en fouillant un peu sur ce forum les solutions ETL, dois-je tourner vers ce type de solution ? J'avais plus l'impression que ces solutions servaient a synchroniser le serveur de prod avec des solutions de BI.

    Merci de m'éclairer :-)

  2. #2
    Modérateur
    Avatar de al1_24
    Homme Profil pro
    Retraité
    Inscrit en
    Mai 2002
    Messages
    9 080
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2002
    Messages : 9 080
    Points : 30 778
    Points
    30 778
    Par défaut
    Le but d'un ETL est toujours de synchroniser deux environnement de données.
    Que ce soit de la prod vers la BI ou dans le cadre d'une migration, c'est bien l'outil à utiliser
    Modérateur Langage SQL
    Règles du forum Langage SQL à lire par tous, N'hésitez pas à consulter les cours SQL
    N'oubliez pas le bouton et pensez aux balises
    [code]
    Si une réponse vous a aidé à résoudre votre problème, n'oubliez pas de voter pour elle en cliquant sur
    Aide-toi et le forum t'aidera : Un problème exposé sans mentionner les tentatives de résolution infructueuses peut laisser supposer que le posteur attend qu'on fasse son travail à sa place... et ne donne pas envie d'y répondre.

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Tout dépend avec quel SGBDR vous travaillez. Par exemple avec MS SQL Server vous avez au moins une dizaines de solutions intégrées pour migrer des données plus en moins en continu et plus ou moins synchronisé :
    1) réplication de type :
    1.1 - transactionnelle
    1.2 - peer to peer
    1.3 - snaphot
    1.4 - fusion
    2) via l'ETL intégré SSIS :
    2.1 - directement
    2.1 - à l'aide d'un outil de suivi du changement :
    2.1.1 - CDC (Change Data Capture)
    2.1.2 - Change Tracking
    3) à l'aide d'un outil d'audit (database audit)
    4) à l'aide d'un outil de gestion de base de données réparties (Service Broker)
    5) manuellement en programmant à l'aide de déclencheurs

    Ma préférence va sans conteste à Service Broker si vos deux bases sont totalement dissemblable. C'est l'outil le plus souple, le plus sûr et le plus rapide...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  4. #4
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Décembre 2006
    Messages
    81
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Décembre 2006
    Messages : 81
    Points : 56
    Points
    56
    Par défaut
    Merci de vos reponses ! Je vais creuser un peu plus le sujet car je ne connais pas du tout tous ces types de replications...

    Pour info la base utilisée en prod est une base MySQL ! Et la nouvelle sera ce que je choisirais... Je pense prendre la meme chose pour simplifier la migration...

    J'avais pensé a mettre en place des triggers sur toutes les tables mais je ne sais pas si on va pas perdre enormement en performance ?

    Ou peut etre avoir un replica des bases en prod qui s'occupe uniquement de ca ?

    Que pensez vous de cette solution ?

  5. #5
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par vgross Voir le message
    J'avais pensé a mettre en place des triggers sur toutes les tables mais je ne sais pas si on va pas perdre enormement en performance ?
    Oui, énormément. Les triggers sont ce qu'il y a de plus contre performant dans le monde des bases de données.
    C'est pourquoi les grands éditeurs (SQL Server, IBM DB2, Oracle)proposent des mécanismes externes et asynchrone afin de ne pas pénaliser les transactions....

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  6. #6
    Membre du Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Décembre 2006
    Messages
    81
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Décembre 2006
    Messages : 81
    Points : 56
    Points
    56
    Par défaut
    Ok merci du conseil j'oubli cette piste tout de suite alors ;-)

    Avez vous des solutions ETL à me conseiller ? Les versions open source sont-elle suffisantes ?

  7. #7
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Tout dépend de la volumétrie et de la fréquence de rafraichissement. Par exemple Talend en version "gratuite" ne permet aucun parallélisme, rendu nécessaire lorsque l'on a des gros volumes à migrer. Du coup bien des gens se font piégés et au final achètent (fort cher) l'outil en version complète lorsque le projet doit être mis en production.

    Avec MS SQL Server par exemple, vous avez un ETL livré avec, multitâche et parallèle, parmi les plus puissant du marché...
    A lire : http://msdn.microsoft.com/en-us/libr...ql.100%29.aspx

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  8. #8
    Membre éprouvé Avatar de Jester
    Inscrit en
    Septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 813
    Points : 1 058
    Points
    1 058
    Par défaut
    Un ETL n'est pas forcément la solution idéale (quoique possible). C'est assez coûteux car à chaque synchro vous allez calculer le différentiel entre les deux bases. Le processus ne sera pas évident et susceptible de générer des erreurs. Le quasi-realtime est très coûteux à obtenir tant en complexité du processus qu'en charge (par trigger ou par CDC via une colonne timestamp).

    Une solution alternative serait de faire une migration progressive via une indirection. Disons que old_base et la base actuelle et new_base la nouvelle. Sous MySQL on peut faire une requête de la première base sur la seconde. L'idée est la suivante :
    1. Remplacer dans l'application actuelle les insert et update par des procédures stockées
    2. Créer la new_base avec votre nouvelle modélisation
    3. Créer une virtual_base identique à la old_base mais donc les procédures stockée pour les insert/update font les opérations dans new_base et à la place des tables il y a des vues vers new_base
    4. Faire le switch de l' application entre old_base et virtual_base
    5. Développer votre nouvelle appli sur new_base
    6. Pour ses évolutions/cleaning l'ancienne application peut utiliser la nouvelle base.


    La limitation est qu'il faut vérifier que la création de virtual_base est possible, si les modèles sont trop différents peut-être que ce n'est pas possible.

  9. #9
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Sauf que votre solution jester pose un problème de fond :
    que se passe t-il si la base dupliquée rejette la commande SQL alors que la première l'a acceptée ? Du style disque plein ?
    C'est une solution brouillonne !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  10. #10
    Membre éprouvé Avatar de Jester
    Inscrit en
    Septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 813
    Points : 1 058
    Points
    1 058
    Par défaut
    Dans ma solution il n'y a aucune duplication de données. virtual_base n'est qu'une facade vers new_base offrant la même interface que old_base.

    Le point critique est la migration de old base version new base, il y aura des transformation donc c'est le point risqué. Cela dit, il est possible de faire des tests en comparant les résultats de virtual_base et de old_base.

    1. clonner old_base (avec les données), virtual_base (il n'y a pas de table donc pas de données) et new_base (il n'y a que la structure) sur un serveur de test, les autres points seront sur le serveur de test
    2. faire la migration old_base -> new_base (un ETL est un bon outil pour ça)
    3. tester la qualité en comparant les données de old_base et new_base en testant les insertions, ... le comportement doit être 100% équivalent. Là encore un ETL peut être utilisé ou une solution plus spécifique.

    Une fois au point, le process peut être exécuté sur le serveur production. Ensuite, old_base peut être supprimée. L'ancienne appli tappe dans virtual_base ce qui revient à utiliser new_base avec l'interface de l'ancienne base de donnée.

Discussions similaires

  1. Réponses: 1
    Dernier message: 14/03/2015, 02h40
  2. Choix Framework - Migration progressive d'une appli
    Par CARNIBAL dans le forum Bibliothèques et frameworks
    Réponses: 1
    Dernier message: 07/12/2012, 20h02
  3. Conseils pour une migration progressive
    Par vgross dans le forum Alimentation
    Réponses: 4
    Dernier message: 19/06/2012, 13h02
  4. Pb migration Access / SQL server
    Par yoyo dans le forum MS SQL Server
    Réponses: 10
    Dernier message: 25/04/2005, 11h39
  5. [Kylix] Migration delphi -> kylix
    Par Christian dans le forum EDI
    Réponses: 1
    Dernier message: 03/04/2002, 23h50

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo