Comment nous avons automatisé la migration de SQL Server vers Java et accéléré 4 fois Cet article est dédié à la modernisation SQL Server sur la base d'un projet réalisé par Ispirer pour une grande entreprise opérant dans le conseil financier. Le client a exploité la puissance d'une base de données SQL Server pour gérer, traiter, accéder et superviser efficacement les informations financières de ses clients. Le client visait à migrer SQL Server vers un cloud tout en optimisant l'architecture système et les coûts de maintenance. de Microsoft L'équipe Ispirer a proposé de transférer la logique métier vers Java car la base de données est utilisée en mode OLTP. Nous analyserons attentivement le sujet et examinerons le projet du client qui consiste à convertir les règles métier de SQL Server en Java. De plus, nous étudierons les raisons qui poussent les entreprises à choisir de migrer le code SQL vers une couche application. Cela impliquera un examen complet de l’ensemble du processus. Pour optimiser les coûts de l'infrastructure cloud, le client a décidé de migrer les tables et les données vers PostgreSQL. Puisque nous sommes spécialisés dans la migration de bases de données et d’applications, le client s’est tourné vers nous pour les tâches suivantes : Déplacement de 815 000 LOC de logique métier vers la couche application en Java. Migration de 300 Go de données et 3000 tables de Microsoft SQL Server vers PostgreSQL. En raison de l'ampleur du projet, le client s'est efforcé de minimiser les dépenses de migration en mettant en œuvre l'automatisation. Pour optimiser l'efficacité de l'Ispirer Toolkit, nous avons déterminé que sa personnalisation devait être effectuée à l'avance. Cette approche nous a permis de livrer un outil à l'équipe du client, avec un taux de conversion T-SCL vers Java d'environ 90%. Examinons maintenant plus en détail la migration des tables et des données. De SQL Server vers PostgreSQL : migration de données et de tables Examinons les raisons pour lesquelles le client a choisi de migrer d'un serveur SQL sur site vers le cloud. Cette transition comporte de nombreux avantages indéniables : Économies de coûts. L'un des principaux facteurs déterminants de la migration de SQL Server vers PostgreSQL dans le cloud est la réduction des coûts. Le client trouvait coûteux de conserver les bases de données SQL Server sur site. Cela était dû au besoin d'équipements spéciaux, de licences de logiciels et d'administrateurs de bases de données qualifiés. PostgreSQL, étant une base de données open source, offre une alternative rentable. Les clients peuvent économiser de l'argent en utilisant le cloud. Ils ne doivent payer que ce qu’ils consomment, au lieu d’effectuer de gros paiements initiaux. De plus, ils peuvent dépenser moins en opérations. Évolutivité. Le cloud computing peut évoluer plus facilement que l'infrastructure sur site pour répondre à des charges de travail plus importantes et à un plus grand nombre d'utilisateurs. Pour qu'un système sur site puisse s'adapter aux besoins d'une entreprise, les organisations devaient acquérir et installer des serveurs physiques, des licences logicielles, du stockage et des équipements réseau pour faire évoluer les services métier dans des environnements informatiques conventionnels. Sur le cloud, la plupart de ces ressources sont disponibles instantanément en quelques clics et peuvent être automatiquement mises à l'échelle en fonction des ressources nécessaires. PostgreSQL dans le cloud offre un haut niveau d'évolutivité, permettant à notre client d'ajuster facilement les ressources en fonction de la demande. Sécurité. L'adoption de la technologie cloud offre des avantages de sécurité notables grâce aux contrôles d'identité avancés, à la gestion des accès et aux systèmes d'authentification fournis par les fournisseurs de cloud. Les fournisseurs de cloud ont souvent de meilleures normes de sécurité que les équipes informatiques internes ou les systèmes locaux, ce qui rend l'environnement des données plus sûr. Un cryptage fort dans le cloud réduit les risques de violations de données. Il comprend une sécurité à plusieurs niveaux, une bonne gestion des clés et des contrôles d'accès sécurisés, qui aident les entreprises à contrôler efficacement l'accès des utilisateurs. De plus, les fournisseurs de cloud supervisent rigoureusement l'accès physique, mettant en œuvre des mesures telles que l'anonymat, la réplication et le cryptage pour renforcer la protection des données. D’ici 2025, environ devraient passer des centres de données physiques aux services cloud. Ce changement est motivé par les avantages de sécurité améliorés fournis par le cloud. 80 % des entreprises Passer de SQL Server à PostgreSQL dans le cloud nécessite une planification et une exécution minutieuses, en tenant compte de considérations spécifiques. Sur la base du projet du client, notre équipe a mis en évidence les étapes suivantes pour moderniser SQL Server : Transformation de schémas et de données. Les données doivent être transformées avec précision pour répondre aux exigences de PostgreSQL. Cela peut impliquer de gérer des nuances telles que les formats de date et le codage des caractères. Contraintes et déclencheurs. Comprendre les distinctions dans l'utilisation des contraintes et des déclencheurs dans les deux bases de données est crucial. Il est nécessaire d'apporter les modifications nécessaires en conséquence. De plus, la fonctionnalité des déclencheurs peut être déplacée dans l'application. Cependant, cette tâche est loin d’être simple, il est donc essentiel de peser le pour et le contre. Optimisation des performances. L'optimisation du processus de migration permet de minimiser les temps d'arrêt et le temps de transfert de données. Il est important d'utiliser la parallélisation, d'optimiser la bande passante du réseau et d'investir dans du matériel puissant pour une migration efficace. Validation et tests des données. Une validation rigoureuse des données migrées est nécessaire pour garantir l’intégrité et la fonctionnalité des données. Des tests approfondis garantissent que les applications fonctionnent de manière transparente avec la nouvelle base de données PostgreSQL. Sécurité et autorisations. Les paramètres de sécurité, les comptes d'utilisateurs et les autorisations dans PostgreSQL doivent être configurés pour correspondre à la configuration d'origine de SQL Server, garantissant ainsi une transition transparente. Pourquoi déplacer la logique métier vers la couche application ? Dans le passé, nos clients utilisaient des procédures stockées pour leur logique métier, pensant que cela améliorerait les performances. Mais soyons honnêtes, le langage SQL n'est peut-être pas le choix optimal pour héberger la logique métier par rapport à la couche application. En fait, SQL interroge ou modifie uniquement les données d'une base de données. Ici, beaucoup peuvent nous lancer des tomates pourries, car le langage SQL est efficace pour effectuer des jointures, des filtrages et des tris complexes afin d'obtenir exactement les données dont vous avez besoin à partir d'une requête et rien de plus. Alors pourquoi changer quoi que ce soit et amener la logique métier au niveau de l’application ? La question semble logique. Répondons-y plus en détail. Ci-dessous, nous avons décrit 4 raisons principales pour lesquelles vous devriez sérieusement réfléchir au transfert de la logique métier vers l'application. La décision du client de déplacer la logique métier vers la couche application a été motivée par les raisons suivantes : Évolutivité Pour l'évolutivité, le stockage de la logique métier au niveau de l'application est la meilleure option. Pourquoi? Parce que, en général, il est beaucoup plus facile de faire évoluer les ressources de votre serveur d'applications que de faire évoluer les ressources de votre serveur de base de données. Ceci est presque universellement reconnu. Pour la plupart des applications Web, l'ajout de serveurs supplémentaires est généralement facile lorsqu'il y a beaucoup de trafic à gérer. Toutefois, la valeur des serveurs d'applications supplémentaires diminue à moins que votre base de données ne puisse également évoluer pour répondre à la demande accrue. La mise à l'échelle d'un serveur de base de données est considérablement plus difficile que la simple ajout de serveurs d'applications. Maintenabilité Le stockage de la logique métier dans une base de données peut créer des problèmes de maintenabilité. La modification de procédures stockées peut perturber de nombreuses applications, limiter l'extensibilité et rendre difficile le respect du principe « Ne vous répétez pas » (DRY). Le code SQL qui dépasse 100 lignes pose souvent des complexités et des difficultés de dépannage. Séparer la logique métier au niveau application peut faciliter l’entrée de nouveaux membres de l’équipe et fournir une plate-forme plus intuitive pour la refactorisation. Facilité de développement SQL est un mauvais choix pour coder les règles métier de votre système. Il n'est pas flexible et nous ne pouvons pas compter sur lui pour représenter des modèles complexes car il ne peut pas créer des abstractions appropriées. Cette limitation est la principale raison pour éviter de l’utiliser pour la logique métier. Il ne s'agit pas d'outils ou de support, mais de l'incapacité de SQL à créer un modèle de domaine simple et expressif, contrairement à la conception orientée objet et fonctionnelle, qui offre plus de possibilités. Réutilisabilité Dans le développement de logiciels, la réutilisation du code est un moyen efficace de gagner du temps et de l'argent lors de l'adaptation du code existant à de nouvelles tâches. La programmation orientée objet (POO) est une méthode qui facilite le recyclage du code, la rendant adaptée à diverses applications. Cependant, SQL, couramment utilisé dans les bases de données, offre une flexibilité limitée pour la réutilisation du code. Les options incluent l'utilisation de « vues » et de « procédures stockées », bien que ces dernières puissent conduire à une abondance de paramètres. Pour garantir le bon choix pour votre projet, il est essentiel d’explorer minutieusement chaque méthode. Conversion de Transact-SQL en Java La conversion de Transact-SQL en Java implique diverses considérations essentielles. Le processus comprend le mappage des types de données SQL avec leurs équivalents Java, garantissant ainsi une représentation précise des données. Cela englobe également la traduction des requêtes SQL en code Java, où Java s'appuie sur des bibliothèques comme JDBC ou Hibernate pour gérer les interactions avec les bases de données. De plus, certaines fonctionnalités d'ESQL n'ont pas d'équivalents directs en Java, ce qui peut donner l'impression que la conversion automatique est inefficace. Au cours de la phase de personnalisation de notre projet, nous avons pu créer un certain nombre de solutions de conversion qui ont amélioré le taux d'automatisation. Ces solutions, initialement considérées comme impossibles à automatiser, se sont finalement avérées efficaces. Examinons en détail certains d'entre eux. Conversion d'une instruction INSERT en combinaison avec un SCOPE_IDENTITY() pour obtenir la dernière valeur d'identité insérée dans une colonne d'identité. Source: ALTER PROCEDURE example1 AS BEGIN Declare @idBit int Declare @c int Insert Into tab (c) Values (@c) Set @idBit = SCOPE_IDENTITY() End Cible: @Service public class Example1 implements IExample1 { @Autowired private JdbcTemplate jdbcTemplate; private static final org.slf4j.Logger LOGGER = org.slf4j.LoggerFactory.getLogger(Example1.class); @Override public Integer spExample1() throws SQLException, Exception { Integer mStatus = 0; KeyHolder keyHolder = new GeneratedKeyHolder(); try { Integer idBit = null; Integer c = null; { final Integer tmpC = c; jdbcTemplate.update(connection-> { PreparedStatement ps = connection.prepareStatement("Insert Into tab(c) \r\n" + " Values(?)", new String[] { "" }); ps.setInt( 1, tmpC); return ps; }, keyHolder); } idBit = Tsqlutils.<Integer > strToNum(keyHolder.getKey().toString(), Integer.class); return mStatus; } catch (Exception e) { LOGGER.error(String.valueOf(e)); mStatus = -1; return mStatus; } } } Conversion de procédure avec plusieurs jeux de résultats. Source: ALTER PROCEDURE [returnSeveralResultSet] @p1 int, @p2 varchar(50) AS Begin select cob_ft, lower(buzon) from tab1 where cob_id = @p1 and cob_ft = @p2 select dep_ft, lower(fiton) from tab2 END Cible: @Service public class Returnseveralresultset implements IReturnseveralresultset { @Autowired private JdbcTemplate jdbcTemplate; private static final org.slf4j.Logger LOGGER = org.slf4j.LoggerFactory.getLogger(Returnseveralresultset.class); private Integer errorCode = 0; private String sqlState = ""; @Override public Map<String, Object> spReturnseveralresultset(Integer p1, String p2) throws Exception { Integer mStatus = 0; Map<String, Object> outData = new HashMap<>(); List<SqlRowSet> outRsList = new ArrayList<>(); SqlRowSet rowSet; try { rowSet = jdbcTemplate.queryForRowSet("select cob_ft, lower(buzon) from tab1 \r\n" + " where cob_id = ? and cob_ft = ?", p1, p2); outRsList.add(rowSet); rowSet = jdbcTemplate.queryForRowSet("select dep_ft, lower(fiton) from tab2"); outRsList.add(rowSet); return outData; } catch (Exception e) { LOGGER.error(String.valueOf(e)); mStatus = -1; return outData; } finally { outData.put("status", mStatus); outData.put("rsList", outRsList); } } } Conversion de la méthode DATEDIFF. Étant donné que Java n'a pas d'équivalent direct, l'équipe Ispirer a développé un équivalent à cette méthode qui convertit String en Timestamp sans format explicitement spécifié. Cela rend le résultat du code épuré et plus facile à lire. L'exemple ci-dessous montre comment il est utilisé. Source: create procedure datediffFn as declare @var1 int set @var1 = DATEDIFF(dd, '1999-01-01', '2000-02-01') set @var1 = DATEDIFF(mm, getdate(), '2000-02-01') set @var1 = DATEDIFF(week, '2005-12-31 23:59:59.9999999', '2006-01-01 00:00:00.0000000'); Cible: public Integer spDatedifffn() throws Exception { Integer mStatus = 0; try { Integer var1 = null; var1 = Tsqlutils.datediff("dd", Tsqlutils.toTimestamp("1999-01-01"), Tsqlutils.toTimestamp("2000-02-01")); var1 = Tsqlutils.datediff("mm", new Timestamp(new java.util.Date().getTime()), Tsqlutils.toTimestamp("2000-02-01")); var1 = Tsqlutils.datediff("week", Tsqlutils.toTimestamp("2005-12-31 23:59:59.9999999"), Tsqlutils.toTimestamp("2006-01-01 00:00:00.0000000")); return mStatus; } catch (Exception e) { LOGGER.error(String.valueOf(e)); mStatus = -1; return mStatus; } } Conversion de la méthode sp_send_dbmail qui envoie un message électronique aux destinataires spécifiés. A cet effet, une classe appelée MailService a été développée. Cette méthode permet d'envoyer des e-mails avec des spécifications détaillées, notamment les destinataires (TO), les destinataires d'une copie (CC), les destinataires en copie carbone invisible (BCC), le sujet de la lettre, le texte principal, les pièces jointes, etc. . Pour garder le code principal épuré, notre équipe a placé la méthode dans une classe distincte. Source: create PROCEDURE spSendDbmail AS BEGIN EXEC msdb.dbo.sp_send_dbmail @profile_name = 'New DB Ispirer Profile', @recipients = 'user1@ispirer.com', @body = '<h1>This is actual message embedded in HTML tags</h1>', @subject = 'Automated Success Message' , @file_attachments = 'C:\Temp\Attached.txt', @body_format='HTML', @copy_recipients = 'user2@ispirer.com', @blind_copy_recipients = 'user3@ispirer.com'; END Cible: import java.util.*; import com.ispirer.mssql.mail.MailService; public class Spsenddbmail { private static final org.slf4j.Logger LOGGER = org.slf4j.LoggerFactory.getLogger(Spsenddbmail.class); public Integer spSpsenddbmail() throws Exception { Integer mStatus = 0; try { MailService.send("New DB Ispirer Profile", "Automated Success Message", "<h1>This is actual message embedded in HTML tags</h1>", "user1@ispirer.com", "user2@ispirer.com", "user3@ispirer.com", "C:\\Temp\\Attached.txt", "HTML"); return mStatus; } catch (Exception e) { LOGGER.error(String.valueOf(e)); mStatus = -1; return mStatus; } } } L'équipe Ispirer a développé une classe XMLUtils pour convertir le type de données XML et ses méthodes, qui sont utilisées pour obtenir des informations à partir de données XML stockées dans une variable XML. Un exemple de mise en œuvre de la méthode : Source: create procedure workWithXml AS begin declare @result bit, @myDoc XML, @myStr varchar(1000), @ProdID INT SET @myDoc = '<Root> <ProductDescription ProductID="1" ProductName="Road Bike"> <Features> <Warranty>1 year parts and labor</Warranty> <Maintenance>3 year parts and labor extended maintenance is available</Maintenance> </Features> </ProductDescription> </Root>' SET @result = @myDoc.exist('(/Root/ProductDescription/@ProductID)[1]') SET @myStr = cast(@myDoc.query('/Root/ProductDescription/Features') as varchar(max)) SET @ProdID = @myDoc.value('(/Root/ProductDescription/@ProductID)[1]', 'int' ) end; Cible: import java.util.*; import com.ispirer.mssql.xml.XMLUtils; public class Workwithxml { private static final org.slf4j.Logger LOGGER = org.slf4j.LoggerFactory.getLogger(Workwithxml.class); public Integer spWorkwithxml() throws Exception { Integer mStatus = 0; try { Boolean result = null; String myDoc = null; String myStr = null; Integer prodID = null; myDoc = "<Root> " + "<ProductDescription ProductID=\"1\" ProductName=\"Road Bike\"> " + "<Features> " + "<Warranty>1 year parts and labor</Warranty> " + "<Maintenance>3 year parts and labor extended maintenance is available</Maintenance> " + "</Features> " + "</ProductDescription> " + " </Root>"; result = XMLUtils.exist(myDoc, "(/Root/ProductDescription/@ProductID)[1]"); myStr = XMLUtils.query(myDoc, "/Root/ProductDescription/Features"); prodID = XMLUtils.<Integer > value(myDoc, "(/Root/ProductDescription/@ProductID)[1]", Integer.class); return mStatus; } catch (Exception e) { LOGGER.error(String.valueOf(e)); mStatus = -1; return mStatus; } } } Grâce à nos efforts de personnalisation, notre équipe a développé avec succès une gamme de techniques pour automatiser la transition de T-SQL vers Java. Cela a considérablement réduit le temps de migration global pour l'ensemble du projet, nous permettant d'accélérer la migration 4 fois par rapport à une éventuelle migration manuelle. La personnalisation de notre boîte à outils a non seulement accéléré la transition, mais a également amélioré l'efficacité globale du projet, démontrant l'impact précieux de nos initiatives de personnalisation. Les méthodes spécifiées dans les exemples sont fournies au client avec les résultats de conversion. Conclusion En conclusion, la transition de la logique métier de Transact-SQL vers Java est un processus à multiples facettes qui nécessite une compréhension globale des deux langages et de leurs fonctionnalités distinctes. Dans cet article, nous avons exploré en profondeur la migration de la logique métier vers une couche d’application et fourni des informations précieuses à ceux qui planifient une telle transition. Le cas de notre client prouve que de tels projets de modernisation peuvent être automatisés, ce qui permet d'économiser considérablement du temps et des efforts lors de la migration. Le projet de notre client constitue un témoignage convaincant du potentiel remarquable de l’automatisation. Cela démontre qu'il existe des facettes de la modernisation dans lesquelles l'automatisation peut réussir à rationaliser des processus qui peuvent initialement sembler au-delà de ses capacités. En fin de compte, adopter la migration de Transact-SQL vers Java est une décision stratégique pour les organisations qui recherchent une plus grande flexibilité, une compatibilité multiplateforme et une évolutivité. Même si elle présente des défis, les avantages en termes de portabilité, de performances et d'adaptabilité aux architectures logicielles modernes font de cette transition un effort intéressant pour ceux qui cherchent à moderniser leurs systèmes et applications de bases de données.
