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 :-)

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

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 +

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 ?

Citation:

---

Envoyé par vgross

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 +

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 ?

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 +

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.

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 +

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.