Au cours des 10 dernières années, VTB a connu une augmentation massive de la charge de calcul. Chaque année, il a augmenté une fois et demie et le volume des titres de compétences - deux. Les services de support ont fait de gros efforts, mais il n'a pas été facile de suivre ce rythme: les plans de requête s'éloignaient, l'espace disque s'épuisait, les mises à jour du code d'application consommaient toutes les ressources. Dans cet article, nous vous montrerons comment résoudre le problème sans dépenser beaucoup sur un autre système IBM p.
En 2013, le traitement des cartes, alors encore banque VTB24, était situé sur l'un des serveurs les plus puissants de l'époque - IBM System p. Cela a été complété par des répliques pour différents rapports. Les répliques de rapports reposaient sur des équipements supplémentaires: une base de données mise à jour tous les soirs pour les rapports quotidiens, des outils pour la réplique active d'Oracle Active Data Guard pour les rapports opérationnels et une base de données pour les rapports de la Banque centrale, que nous mettons à jour mensuellement.
Nous avons activement personnalisé la fonctionnalité des systèmes - la majeure partie du code d'application était occupée par des améliorations internes. Dans le même temps, les données ont augmenté très rapidement. En conséquence, le plan de requête pour quatre bases se détériorait régulièrement. Les systèmes avant étaient lents. D'un point de vue technique, il y avait une autre difficulté: la charge OLTP des transactions par carte était mélangée avec la charge DWH / DSS de fonctionnalités et de rapports personnalisés.
Le moyen standard de sortir de cette situation est de vider les ressources et de basculer vers un sous-système de stockage de données plus raide. Nous avons proposé une option plus intéressante - nous avons pris pour rapporter des répliques deux complexes matériels et logiciels Oracle Exadata optimisés pour le fonctionnement de la base de données.
Le complexe de traitement a été divisé en zones «chaudes» et «chaudes». La zone chaude n'a bougé nulle part avec IBM System p et seule sa base de données y a été conservée. La zone «chaude» était une copie de la base de données principale sur Exadata. Voici tous les rapports et fonctionnalités personnalisées. Données répliquées à l'aide d'Oracle GoldenGate.
Nous avons effectué des tests de répliques sur Exadata: en moyenne, les rapports sont devenus cinq fois plus rapides grâce à l'architecture et aux fonctionnalités du logiciel Oracle Exadata Storage - analyses intelligentes, index de stockage, filtres de floraison, etc. Le temps de préparation des rapports pour la Banque centrale a été réduit d'un facteur dix, et maintenant certains rapports sont préparés en moins d'une heure. La principale chose à faire pour optimiser les requêtes lors du portage vers Exadata était de supprimer les indices qui permettaient auparavant de travailler sur l'ancienne plate-forme.
Nous avons réalisé une étude de faisabilité, comparant les options pour différents paramètres avec l'extension habituelle des systèmes actuels et avec l'implication de deux complexes Exadata.
- Performance. 40 000 IOPS contre 400 000 IOPS chez Exadata. La solution Oracle est orientée vers de grandes quantités de données, l'analyse complète de la table est beaucoup plus rapide.
- Options de personnalisation. Dans la solution standard, nous ne pouvons pas changer la structure des objets sans changer la base de données productive, cela est interdit par le vendeur. Dans Exadata, nous pouvons supprimer les index inutiles, ajouter les index nécessaires et améliorer la réponse du système.
- Mise à l'échelle. Exadata offre une augmentation linéaire de la productivité à un coût relativement inférieur.
- Rapports. La vitesse de génération de rapports avec le complexe Exadata augmente de 5 fois et avec la mise à l'échelle des systèmes existants - de 1,5.
- Service. L'infrastructure Oracle dispose d'un support technique unifié, d'un système de mise à jour unique pour les serveurs, les sous-systèmes de disques et l'infrastructure réseau. Avec une mise à l'échelle normale, vous devez travailler avec différents fournisseurs - il y a plus de temps d'arrêt et tout autre inconvénient.
- Coût. Exadata gagne ici.
Au début, la réplication GoldenGate s'est avérée être un point faible: dans le cas de transactions longues à la source, elle a pris du retard. Nous avons résolu ce problème en mettant à jour et en affinant certains processus d'application. Après cela, travailler avec Exadata ne nous a révélé que des avantages.
Nous avons introduit des index et un partitionnement personnalisés, ce qui nous a permis d'augmenter les performances des fonctions personnalisées. IBM ne permet pas cette optimisation.
Le transfert des rapports analytiques vers la zone «chaude» a permis de réduire la profondeur de stockage des données historiques de la zone «chaude». Cela a réduit le coût d'un stockage coûteux. Géré pour accélérer l'insertion dans les index. La suppression des données via le module de nettoyage a été filtrée au niveau GoldenGate, par conséquent, la réplique contenait de nouvelles données et toute l'histoire;
Exadata utilise la compression de colonne hybride (HCC), ce qui économise considérablement l'espace disque. Les données de plus d'un an sont compressées par la méthode d'archivage bas, de plus d'un mois par la méthode de compression avancée, les données plus récentes ne sont pas compressées pour augmenter la vitesse.
Quant à la mise à niveau, il est plus efficace de remplacer des cellules de stockage entières dans Exadata par des cellules avec des disques plus spacieux et des processeurs puissants. Mais vous pouvez utiliser des cellules de stockage de différentes versions dans le même système - Oracle le permet.
Les rapports de traitement des cartes, mis en œuvre sur les technologies Oracle Exadata et Database, ont bien fonctionné jusqu'à présent, et de nouveaux systèmes bancaires sont construits sur le même principe.