Les systèmes de comptabilité d'entreprise se caractérisent par une augmentation progressive du volume des bases de données en raison de l'accumulation d'informations historiques. Au fil du temps, la taille de la base de données peut atteindre des tailles telles qu'elle provoque un certain nombre de problèmes de performances, de maintenance, d'espace disque disponible, etc. Aujourd'hui, nous considérons deux approches pour résoudre ce problème: l'augmentation des ressources matérielles et le pliage des données historiques.
Présentation
Cet article explique le problème du pliage de bases de données particulièrement volumineuses sur la plate-forme MS SQL Server. La solution à ce problème est décrite à l'aide de la technologie de réplication DBREPLICATION de Softpoint.
Problème
Chaque type de système comptable peut commencer à manifester ses propres caractéristiques spécifiques. Par exemple, dans les systèmes basés sur la plate-forme 1C, des problèmes surviennent avec des opérations de routine telles que la mise à jour de la configuration, la mise à jour de la plate-forme 1C. Au fur et à mesure que la base de données se développe, la situation s'aggrave progressivement; tôt ou tard, des mesures doivent être prises.
Approche n ° 1: matériel
La solution la plus évidente et techniquement transparente consiste à augmenter les ressources matérielles. Il peut s'agir soit de l'achat de serveurs plus productifs, d'un stockage sur disque, etc., soit de la location d'équipements plus puissants dans un centre de données tiers ou dans le cloud.
Si vous procédez de cette façon, une bonne option consiste à placer la base de données dans le cloud Microsoft Azure. Azure propose plusieurs options d'architecture pour l'hébergement de la base de données: MS SQL sur la machine virtuelle Azure et trois options pour Azure SQL Database dans le cloud. Par conséquent, il est possible de choisir l'option de placement la plus optimale en fonction des caractéristiques d'une base de données particulière et de ses conditions de fonctionnement.
Azure présente un certain nombre d'avantages par rapport à l'achat de votre propre équipement. L'un des principaux est les énormes capacités matérielles qu'Azure peut fournir. Ainsi qu'une approche flexible de l'utilisation de ces capacités en fonction de la charge réelle. Par exemple, vous pouvez acheter des capacités supplémentaires pour la période de la «haute saison» de votre entreprise, ou à la fin de la période de reporting, afin que les pics puissent passer sans problème. Et le reste du temps, utilisez une configuration plus budgétaire des ressources. Ainsi, d'une part, au bon moment, vous avez accès à l'énorme potentiel de ressources d'Azure (qui, soit dit en passant, ne cesse de croître), et d'autre part, vous ne pouvez pas surpayer une capacité excédentaire lorsque vous n'en avez pas besoin.
Cependant, malgré sa relative simplicité, l'augmentation des ressources matérielles n'est pas une solution universelle. Premièrement, l'effet positif est souvent loin d'être proportionnel aux investissements financiers (il y a beaucoup d'investissements - il y a peu d'effet). Deuxièmement, l'effet est temporaire, car la base continue de croître et nécessite plus de ressources, plus d'investissements financiers.
Dans tous les cas, cette approche a droit à la vie et est largement utilisée. Mais nous ne nous attarderons plus là-dessus, puisque l'objet principal de l'article n'est pas une approche «matérielle», mais une approche «logicielle», décrite ci-dessous.
Approche n ° 2: convolution de la base
Une solution plus radicale est la convolution de la base de données, c'est-à-dire la suppression des données historiques non pertinentes. Dans la base de données effondrée, il n'y a que des données pour une période opérationnelle relativement petite, généralement pas plus de 1-2 ans. De toute évidence, le degré de réduction dans chaque cas est différent et il est difficile de nommer des chiffres spécifiques. Et pourtant, à titre indicatif, nous prendrons un indicateur d'une diminution de la base de 50 à 70%, c'est-à-dire environ 2-3 fois, à peu près le même montant le plus souvent et il s'avère en pratique, moins ou vice versa plus - c'est rare.
Nous ne nous attarderons pas sur les gains obtenus. De toute évidence, si la base est réduite de 2 à 3 fois ou plus, l'effet de performance sera très puissant et à long terme, et des investissements supplémentaires dans le composant matériel peuvent être évités. Et le mécanisme de convolution, une fois développé et rodé, pourra être réutilisé à l'avenir. En général, c'est une excellente solution efficace avec des résultats garantis.
La complexité de la mise en œuvre de la convolution
Mais malgré toute son efficacité, la convolution a un très gros problème. Et il ne s'agit même pas de développer le mécanisme de convolution lui-même. Oui, ce développement est également une tâche difficile, mais il est en quelque sorte résolu. La chose est différente. Lorsque la base de données a une taille de plusieurs centaines de gigaoctets ou a franchi la ligne de téraoctets, il s'avère qu'il est tout simplement physiquement très difficile d'effectuer l'opération de pliage. Inévitablement, tout un complexe de difficultés interconnectées se pose, considérons-les.
- Intensité des ressources des opérations de pliage - l'équipement est lourdement chargé.
- Pendant la convolution, non seulement un grand tableau de données est physiquement supprimé, mais aussi de nombreuses opérations connexes gourmandes en ressources sont effectuées: diverses sélections, vérifications, regroupements, indexation, journalisation, déplacement de données entre les tables, etc. Ce fait est particulièrement important car la base de données pliable, en règle générale, est déjà lourdement chargée et n'a pas un excès de capacité.
- Interférence avec les utilisateurs.
- Il est extrêmement difficile, voire impossible, d'effectuer la convolution directement dans la base de données de travail en parallèle avec le travail de l'utilisateur en raison de la charge supplémentaire élevée et des verrous créés par le processus de convolution.
- Il n'y a pas de fenêtre technologique.
- Une fenêtre technologique d'une durée suffisante, lorsque les utilisateurs ne travaillent pas, n'est tout simplement pas disponible pour la convolution. Après tout, le processus de pliage pour des bases de données de cette taille est généralement de plusieurs dizaines d'heures ou de plusieurs jours.
- Risques élevés lors du pliage directement sur la base de travail.
- L'approche, lorsque l'algorithme de convolution est appliqué directement à la base de travail, est elle-même très risquée pour un certain nombre de raisons. L'un d'eux - les possibilités de vérification finale des résultats de la convolution sont très limitées (pas de temps).
- Durée inacceptable d'une approche itérative.
- Vous pouvez essayer d'éviter un goulot d'étranglement - une fenêtre technologique, et effectuer une itération en petites portions itératives directement dans la base de production, en sélectionnant la taille de chaque portion afin qu'elle s'insère dans les fenêtres technologiques existantes. Mais cette voie est également le plus souvent inapplicable, car, d'une part, le processus de détourage s'étire sur une période inacceptablement longue (plusieurs semaines ou mois), et d'autre part, la complexité du mécanisme de pliage augmente, le coût total pour assurer un processus de coupe ininterrompu pendant si longtemps , les risques du projet dans son ensemble augmentent radicalement.
- Comment compresser des vides dans un fichier de données!?
- Lors de la suppression des informations historiques de la base de données, son fichier de données ne diminue pas réellement (et souvent même augmente légèrement), il crée simplement d'énormes vides à l'intérieur. Et vous devez en quelque sorte vous en débarrasser pour que le fichier de données soit réduit. Sinon, le gain est perdu en termes d'espace disque. Une option consiste à exécuter un SHRINK typique. Et sur de tels volumes, c'est une procédure très longue (plusieurs heures, voire des dizaines d'heures).
Ainsi, la convolution est une tâche très non triviale. Il ne suffit pas de développer un mécanisme de convolution, il faut aussi l'appliquer. De plus, l'application devient souvent un goulot d'étranglement.
Remarque: Ensuite, nous laissons entre parenthèses le développement du mécanisme de convolution lui-même (en d'autres termes, l'algorithme de suppression des données historiques), quel que soit le moyen de sa création. Et nous nous concentrons uniquement sur l'application du mécanisme déjà mis en œuvre au combat.
Solution utilisant DBREPLICATION
Cela semblerait une impasse. Mais il reste des solutions. Il existe une technique efficace qui vous permet de démêler tout l'enchevêtrement des difficultés, d'éliminer les risques et est garantie d'atteindre l'objectif. Cela implique l'utilisation de la technologie d'échange de données DBREPLICATION. La solution convient à la fois à l'option d'infrastructure traditionnelle et à Microsoft Azure basé sur le cloud. Brièvement, l'essentiel est le suivant.
- Un clone de la base de données est créé, l'échange de données unidirectionnel entre le clone et la base de données principale est configuré à l'aide de DBREPLICATION. Il est autorisé que la base de données principale et / ou son clone se trouvent (les deux ou l'un d'entre eux) dans le cloud Microsoft Azure.
- Dans le clone, les utilisateurs ne fonctionnent pas, là commence le processus de convolution. Étant donné que le processus de pliage ne dérange personne, il peut durer toute la journée sans interruption aussi longtemps qu'il le faut. Ainsi, le lien vers la durée de la fenêtre technologique disparaît!
- Les utilisateurs sans interférence travaillent dans la base de données principale. Et la technologie DBREPLICATION transfère automatiquement toutes les modifications de la base de données principale vers la version pliable à grande vitesse. Ainsi, le clone est à jour en termes de données opérationnelles.
- Après l'achèvement de la convolution, en règle générale, une vérification détaillée du résultat est effectuée avec la participation de spécialistes techniques et d'utilisateurs professionnels du client. Et ce processus peut durer assez longtemps (plusieurs heures ou jours). Dans la méthodologie considérée, il n'y a pratiquement pas de limite de temps, par conséquent, la vérification peut être allouée autant de temps que nécessaire.
- Une fois la convolution et la vérification terminées, tous les utilisateurs passent au clone tronqué et à partir de ce moment, il devient la base principale. Et la base d'origine non circoncise sert d'archive de données historiques.
- Un avantage supplémentaire est la possibilité de basculer la réplication dans la direction opposée lorsque les utilisateurs passent à une base de données réduite. Cela offre une sécurité supplémentaire, car si «quelque chose ne va pas», vous pouvez rapidement basculer les utilisateurs vers la base de données non circoncise sans perdre les données saisies.
- S'il est nécessaire de maintenir la base de données d'archives à jour, vous pouvez basculer la réplication dans le sens opposé et transférer les modifications de la base de données réduite à celle d'archivage.
Fig.1. Diagramme schématique du découpage de la base de données utilisant la technologie DBREPLICATION.
Fig.2. Possibilité d'héberger des bases de données pliantes dans le cloud MS Azure.
Ainsi, la technique de convolution décrite dans la base de données de clones étend tous les goulots d'étranglement. Élimine la dépendance à la fenêtre technologique. Dans le clone, le package ne dérange personne et personne ne la dérange. Vous pouvez utiliser en toute sécurité les ressources maximales du clone, et également accorder suffisamment d'attention à la vérification finale.
Reste à savoir quelle technologie d'échange peut être utilisée dans ce schéma? Pourquoi DBReplication?
Pourquoi DBReplication?
Dans la méthodologie décrite, l'élément clé est la technologie d'échange, qui assure la synchronisation de la base de données découpée avec la principale. En principe, la technologie d'échange peut être quelconque si elle remplit trois conditions clés essentielles:
- Compatibilité avec la plateforme d'applications métier, dont la base s'effondre.
Exemple: si nous réduisons la base de données 1C, toutes les technologies d'échange ne sont pas compatibles avec la structure de base 1C, en particulier, la réplication MS Transaction classique n'est pas compatible, car elle modifie la structure de la table.
- Performance. La technologie d'échange doit être garantie pour faire face au flux de changements qui se produit dans la base de travail pendant la convolution.
Explication: dans cet article, nous entendons principalement des bases de données très chargées avec un taux élevé de changement de données. La convolution durera des dizaines d'heures, peut-être plusieurs jours, peut-être même qu'il y aura plus d'une itération de la convolution. Pendant ce temps, les utilisateurs feront d'énormes changements. De nombreuses technologies de partage ne peuvent tout simplement pas le gérer. Et vous n'avez pas seulement besoin de faire face, il est conseillé de faire face à l'approvisionnement.
- La principale applicabilité aux conditions du problème.
Explication: ce point semble peut-être évident, mais nous pouvons néanmoins le distinguer. A savoir: n'oubliez pas que les données de la base de données source et du clone ne sont pas égales! Ce fait balaie automatiquement toute une classe de technologies puissantes et productives basées sur la synchronisation des journaux de transactions - toujours active, l'envoi des journaux, la mise en miroir, etc.
En outre, la technologie d'échange devrait être efficace en termes d'autres indicateurs:
- Fiabilité et autonomie de fonctionnement. Puisque nous parlons du transfert d'énormes quantités de données, et pendant assez longtemps, l'équipe de projet n'aura tout simplement pas la capacité physique de traiter manuellement les problèmes d'échange, les collisions et les échecs, de vérifier la qualité des données, etc. Par conséquent, la technologie d'échange devrait être aussi fiable que possible en termes de qualité des données transmises, aussi autonome et automatisée que possible.
- Interfaces utilisateurs de qualité pour le contrôle et la gestion.
- Facile à déployer et à configurer. La technologie d'échange ne devrait pas imposer des exigences excessivement élevées aux qualifications des spécialistes pour son ajustement.
Sans ces qualités, la technologie d'échange menace de passer d'un élément clé d'économie de la méthodologie à son «maillon faible», introduit des risques sérieux et menace l'ensemble du projet. Et puis l'idée originale perd son sens.
Cependant, la technologie DBReplication satisfait certainement toutes les exigences et assure le succès du projet de rollup.
Notez les principaux facteurs grâce auxquels DBReplication réussit dans cette tâche:
- Taux de change très élevé. Notez certaines fonctionnalités qui offrent de la vitesse:
- DBReplication est une réplication transactionnelle, chaque modification commence à être transmise immédiatement après la validation de la transaction;
- L'architecture interne du sous-système de transport utilise des solutions telles que le traitement parallèle multithread des files d'attente, une approche en pipeline, la compression de flux, le traitement des transactions par lots, l'utilisation de Bulk Insert et d'autres.
- Transport implémenté sur la base des services Windows, équipé de nombreuses fonctionnalités pour assurer un bon fonctionnement. Ceux-ci incluent: la récupération automatique des échanges après des interruptions de communication, le travail sur des canaux de communication instables faibles, le traitement automatique des conflits de version (pour l'échange bidirectionnel), l'adaptation automatique en cas de changements dans la structure des tableaux d'une application métier, etc.
- Mécanisme de livraison de données garanti. Adhésion stricte à l'intégrité transactionnelle et à la cohérence dans le transfert des modifications.
- Ne modifie pas la structure de table de l'application métier. Par conséquent, en particulier, il peut être utilisé avec succès lors du pliage des bases de données 1C.
- Interface utilisateur développée qui vous permet de gérer de manière centralisée le système d'échange "à partir d'une seule fenêtre", toutes les informations de service sont collectées et affichées en ligne.
- Facile à déployer et à configurer.
- Adapté à la plateforme 1C. L'utilisateur ne travaille pas avec des tables, mais avec des objets de métadonnées 1C familiers.
- Toute version de MS SQL, à partir de 2005, de Standard à Enterprise, déployée localement et située dans le cloud de MS Azure; d'un point de vue Azure, les options d'hébergement de machine virtuelle et d'hébergement Azure SQL DB sont autorisées, y compris une instance gérée de la base de données Azure SQL ( instance gérée ).
- DBReplication est une solution fiable prête à l'emploi qui a été testée par de nombreux projets dans diverses conditions et tâches.
- Si DBREPLICATION est utilisé en mode d'échange unidirectionnel, le sens d'échange peut être commuté.
De plus, nous notons une autre caractéristique importante:
- DBREPLICATION peut fonctionner dans un mode d'échange bidirectionnel, lorsqu'il est possible d'entrer / modifier des données simultanément dans toutes les bases de données participant à l'échange. Le nombre de bases pouvant être incluses dans le circuit d'échange n'est pas limité.
Exemple d'application pratique
Une grande entreprise russe possède un système de comptabilité des applications basé sur la plate-forme 1C 8 + MS SQL Server. La base opérationnelle principale a depuis longtemps dépassé les 2 téraoctets et continue de croître. Dans le même temps, la charge augmente de plus en plus: à la fois transactionnelle et analytique. En fin de compte, un certain nombre de raisons ont été formées pour la convolution de la base. Il a été décidé de couper les données historiques pour le début de 2017. La technique décrite ici à l'aide de DBReplication a été sélectionnée.
En soi, l'algorithme de convolution a été décidé d'être implémenté principalement par TSQL avec de petites inclusions d'outils 1C typiques. La tâche était compliquée par le fait que tous les objets appliqués (tables) ne pouvaient pas être réduits à la date prévue, car les fonctionnalités métier exigeaient que dans un certain nombre des sous-systèmes les plus importants, les données historiques soient présentes dans leur intégralité jusqu'à une profondeur de 5 à 7 ans. Par conséquent, du point de vue du volume de la base de données, l'effet de la convolution n'était pas aussi important que nous le souhaiterions. Une analyse préliminaire a été réalisée, qui a montré que, compte tenu des restrictions objectives, environ 33% du volume initial serait supprimé. Mais cela a été évalué par le Client comme un bon résultat, car le gain est non seulement dans le volume de la base de données en tant que tel, mais aussi dans la vitesse des tables individuelles, et les tables des sous-systèmes effondrés ont diminué en volume de plus de 33% - de 46% à 77% (en 2- 3 fois).
Examinons de plus près certains indicateurs et faits de l'utilisation réelle de la convolution. La durée de la convolution directe des données était d'environ 12 heures. La synchronisation des modifications accumulées à l'aide de DBREPLICATION a pris environ 1 heure. Un des points clés du projet a été la vérification finale de la base minimisée, réalisée par les spécialistes du Client. Il convient surtout de noter sa durée - ce processus a pris environ 1 semaine. Cette durée est due au fait que la vérification a été très approfondie et complète, avec la participation de spécialistes de différents profils, y compris la construction d'un modèle de données dans un système externe. Pendant tout ce temps, la base minimisée a été automatiquement synchronisée avec la base de données de combat actuelle via DBREPLICATION. La vérification a réussi. Et les utilisateurs ont été transférés vers une base de données réduite. La base de données précédente a été transférée au statut d'archive, avec un accès en lecture seule. La synchronisation ultérieure n'a pas été nécessaire, la réplication a donc été désactivée.
Résumé du projet:
- La technique appliquée a complètement porté ses fruits, grâce à elle, il y a eu suffisamment de temps pour terminer la convolution elle-même, ainsi que pour vérifier de manière approfondie les données, ce qui a radicalement minimisé les risques d'ignorer certaines erreurs et de passer à une base de données effondrée.
- Convolution terminée avec succès:
- Le volume total de la base de données opérationnelle a diminué de 33%. Il n'a pas été possible d'obtenir un effet plus important sur le volume de la base de données pour des raisons objectives, en raison des restrictions sur le pliage de certains grands sous-systèmes.
- Le volume des tables activement utilisées de sous-systèmes effondrés a diminué de 46 à 77% (2-3 fois).
Conclusion
DBReplication est une solution fiable prête à l'emploi qui est présente sur le marché depuis de nombreuses années, testée par de nombreux projets dans diverses conditions. Dans la technique de convolution considérée, DBReplication assume complètement l'une des sous-tâches clés - la synchronisation de la base de données. Dans le cas de bases de données particulièrement volumineuses, des exigences très strictes sont imposées au système d'échange et DBReplication les satisfait pleinement. Il résout sa tâche de manière fiable et efficace, garantissant ainsi la réussite du projet dans son ensemble.
Pour quelles autres tâches pouvez-vous utiliser DBREPLICATION
Un ensemble de fonctionnalités et d'avantages compétitifs permet à DBReplication d'être utilisé pour résoudre un certain nombre de problèmes. Pour référence, nous les listons.
- Redondance de la base de données et tolérance aux pannes.
- Équilibrage de charge: redistribution entre 2 instances de base de données synchrones ou plus.
- Transition contrôlée vers de nouvelles versions logicielles (MS SQL, 1C), la technique est similaire à la technique de convolution.
- Construire un système d'information distribué avec échange à haute vitesse basé sur DBReplication. En particulier, remplacer la technologie d'échange d'entreprise existante par une technologie plus productive et plus efficace - DBREPLICATION.