Vous cherchez des conseils sur la façon d'intégrer les données de plus de 100 bases de données client dans une base de données de rapports centralisée

Je suis développeur SQL (pas DBA ni architecte) pour une petite entreprise SaaS (~ 50 employés). Je suis chargé de trouver comment:

Déchargez les rapports opérationnels de nos 100+ bases de données OLTP
Autoriser l'exécution de ces rapports sur les données de plusieurs bases de données client
Positionner notre entreprise pour fournir plus de solutions basées sur l'analyse à l'avenir

J'ai lu un certain nombre d'articles sur diverses technologies comme la réplication transactionnelle (en particulier le modèle d'abonné plusieurs-à-un / central), le courtier de services SQL, l'envoi de journaux, Change Tracking (CT) et Change Data Capture (CDC, je crois comprendre que c'est uniquement pour les entreprises), et je ne sais pas quelle est la meilleure voie à suivre.

J'espère que certains d'entre vous possédant une expertise en matière d'intégration auront peut-être rencontré une configuration similaire à la nôtre et pourront me montrer la voie à suivre ou me diriger vers des ressources qui pourraient être utiles.

En raison de contraintes de coût, notre solution doit fonctionner dans SQL Server Standard Edition. De plus, la solution doit être raisonnable à soutenir / maintenir au sein de notre petite organisation.

Configuration de base:

Nous avons actuellement plus de 100 bases de données client individuelles, la plupart déployées sur des serveurs SQL dans notre centre de données, mais certaines déployées sur des serveurs clients dans leur centre de données dans lesquels nous pouvons nous éloigner. Ce sont toutes des bases de données SQL Server 2008 R2, mais nous prévoyons de passer à SQL 2016 prochainement.

Nous utilisons des projets de base de données et des dacpac pour garantir que le schéma est le même dans toutes les bases de données client qui seraient intégrées. Cependant, comme nous ne forçons pas tous les clients à mettre à niveau vers de nouvelles versions en même temps, certaines différences de schéma sont possibles entre les mises à niveau. La solution doit être suffisamment flexible pour ne pas se casser si le client A est sur la version 1.0 du logiciel et le client B est sur la version 1.1.

Les rapports opérationnels sont actuellement exécutés directement à partir de la base de données OLTP de chaque client. Nous sommes préoccupés par l'impact que cela aura sur les performances de l'application si nous ne la déchargeons pas.

Exigences de haut niveau:

Nos clients sont des départements de traitement stérile des hôpitaux (SPD) qui souhaitent des rapports à jour sur ce qu'ils ont traité jusqu'à présent, où se trouve l'inventaire, etc. Étant donné que l'un des principaux objectifs de cet effort est de mieux prendre en charge les rapports opérationnels, nous souhaitons que les données soient aussi proches que possible du temps réel pour continuer à répondre aux besoins des clients.

Actuellement, nous avons certains SPD dans des bases de données distinctes qui font en fait partie du même système hospitalier. Ces clients souhaitent pouvoir rapporter tous les SPD de leur système.

Stratégiquement parlant, nous aimerions pouvoir agréger facilement les données de tous nos clients pour soutenir nos initiatives d'analyse interne. Nous nous attendons à ce que nous puissions utiliser les données opérationnelles collectées comme source pour les dépôts de données / entrepôts.

Pensées jusqu'ici:

La réplication transactionnelle semble fournir la solution la plus "en temps réel". J'ai trouvé cette réponse particulièrement utile, mais je crains qu'avec le potentiel de différences de schéma, cela ne fonctionne pas pour nous: réplication plusieurs à un SQL Server

L'envoi de journaux ne semble pas idéal étant donné que le journal ne peut pas être restauré lorsque les requêtes sont actives. Soit je dois expulser tout le monde pour que le journal puisse être restauré, soit les données deviendront périmées. Je ne sais pas si cette méthode pourrait être utilisée pour centraliser les données de plusieurs bases de données, car chaque journal expédié ne concernerait que la base de données individuelle dont il est issu.

À l'aide de SQL Service Broker, la latence peut être imprévisible si une file d'attente n'a pas pu suivre le nombre de messages à traiter.

CT identifie uniquement une version pour chaque ligne de table. La latence dépendrait de la rapidité avec laquelle nous pourrions traiter quelque chose comme un package SSIS sur chaque base de données pour récupérer les données et les insérer dans un référentiel central.

Faut-il envisager de répliquer chaque base de données individuellement, puis peut-être utiliser une sorte de technique de virtualisation des données pour combiner les données des différentes sources répliquées?

Tout conseil ou orientation que vous êtes prêt à fournir serait grandement apprécié.

— bperry
source

En raison de vos besoins en temps quasi-réel, je ne considérerais que le traitement basé sur les événements avec certaines implémentations de file d'attente de messages (pour les garanties de livraison). J'espère que cela vous aidera

— Grimaldi

Je jetterais HTAP dans le mix. en.m.wikipedia.org/wiki/Hybrid_Transactional/… BIML et SSIS pour remplir le magasin commun.

— Michael Green

@Grimaldi, recommanderiez-vous d'utiliser SQL Service Broker pour implémenter le traitement basé sur les événements / les files d'attente de messages ou une autre technologie de messagerie?

— bperry

Merci pour la suggestion, @MichaelGreen. Fondamentalement, il semble que HTAP nous permettrait d'utiliser nos bases de données existantes pour OLTP et OLAP en ajoutant des index columnstore non clusterisés (NCCI) à nos tables. Les requêtes de rapport utilisent le NCCI pour ne pas interférer avec les opérations transactionnelles. SQL 2016 inclut la prise en charge HTAP dans Standard Edition (SE), mais il semble que le cache columnstore soit limité à 32 Go sur l'ensemble de l'instance SQL. Cela pourrait être un problème pour nous car nous avons des dizaines de bases de données sur la même instance. microsoft.com/en-us/sql-server/sql-server-2016-editions

— bperry

Oui columnstore mais aussi en mémoire, si les spécifications de votre serveur vous y autorisent. J'ai entendu Sunil Agarwal en parler récemment. La règle de base de MS était d'environ 3% de dégradation d'OLTP au profit de la génération de rapports à latence nulle. Malheureusement, il n'y a pas de déjeuner gratuit; vous pouvez créer de nouvelles instances pour contenir la base de données de rapports ou vous pouvez créer une nouvelle instance pour obtenir suffisamment d'espace libre pour prendre en charge HTAP. Je ne préconise pas ce modèle. Cela peut ne pas fonctionner pour vous. Je voulais juste vous faire savoir qu'il existait.

— Michael Green

Réponses:

Faut-il envisager de répliquer chaque base de données individuellement, puis peut-être utiliser une sorte de technique de virtualisation des données pour combiner les données des différentes sources répliquées?

Oui. Vous pouvez héberger plusieurs bases de données d'abonnés sur une seule instance, puis les interroger avec des vues ou les charger dans une base de données consolidée.

— David Browne - Microsoft
source

Existe-t-il une manière plus élégante de configurer ces vues en plus de quelque chose comme ... SELECT Field1, Field2, Field3 FROM [Database1]. [Schema]. [TableName] UNION ALL SELECT Field1, Field2, Field3 FROM [Database2]. [Schema ]. [TableName]

— bperry

Selon votre description ci-dessus, le lien ci-dessous vous aidera, moi et moi, à travailler sur le même scénario. Plusieurs éditeurs avec un seul abonné.

Ajoutez une autre colonne comme server_id avec une valeur par défaut comme 1,2,3 et ainsi de suite et faites-en une clé primaire composite.
Lors de la création des publications et de l'ajout d'articles, la propriété d'article Action si le nom est utilisé doit être définie sur Supprimer les données. Si l'article a un filtre de ligne, supprimez uniquement les données qui correspondent au filtre. Cela peut être défini à l'aide de la boîte de dialogue Propriétés de l'article de l'Assistant Nouvelle publication ou à l'aide des procédures stockées de réplication sp_addarticle et en spécifiant une valeur de suppression pour l'argument @pre_creation_cmd. De cette façon, lorsque l'abonné central est initialisé ou réinitialisé à partir de plusieurs instantanés de publication, les données instantanées précédemment appliquées seront conservées car seules les données correspondant à la clause de filtrage seront supprimées.

http://www.sqlrepl.com/sql-server/central-subscriber-model-explained/

— Gulrez Khan
source

merci pour l'article. En utilisant le modèle d'abonné central, avez-vous déterminé comment vous allez gérer les mises à jour du schéma de vos éditeurs (par exemple, avec les mises à niveau de version)? Obligerez-vous à mettre à jour simultanément toutes les bases de données des éditeurs? Dans mon environnement, nous n'avons pas toujours cette option et c'était ma principale hésitation à poursuivre un modèle de réplication d'abonné central. S'il y a un moyen de contourner cette barrière, j'aimerais savoir!

— bperry

Je n'utilise pas 'Update Publisher'.J'ai divisé la base de données en deux parties comme (deux types de réplication) une partie du tableau dans l'éditeur détaillé (éditeur vers abonné centralisé) et une autre est l'éditeur principal (abonné centralisé pour tous les éditeurs) .... Mon abonné centralisé fait également partie du groupe de disponibilité AlwaysOn pour mon travail de réplique secondaire en tant que serveur de rapports.

— Gulrez Khan

Permettez-moi de m'assurer que je comprends votre solution. Supposons que l'éditeur A est sur la version 1 et l'éditeur B sur la version 2. 1) Vous avez désactivé la réplication des modifications de schéma sur les deux éditeurs (en utilisant replicate_ddl = 0 lors de l'installation). 2) La version 2 comprend une nouvelle colonne, vous devez donc l'ajouter manuellement à l'abonné central. 3) Dans Publisher B (mis à niveau), vous devez ensuite ajouter manuellement la nouvelle colonne dans la réplication (à l'aide de sp_articlecolumn). Aucune modification n'est apportée à Publisher A. Cela permettrait-il aux deux éditeurs de continuer à répliquer vers l'abonné central sans interrompre la réplication?

— bperry

voir le lien ci-dessous .. dba.stackexchange.com/questions/142449/…

— Gulrez Khan

voir aussi ceci. dba.stackexchange.com/questions/146070/…

— Gulrez Khan

Une architecture possible:

Considérez le reporting comme une solution basée sur un entrepôt de données.

Un entrepôt de données est généralement une base de données avec un schéma qui représente le sous-ensemble requis des systèmes source. AdventureWorks et AdventureworksDW démontrent cette modélisation.

Ensuite, l'ETL: déplacement des données des sources vers l'entrepôt de données.

Une implémentation possible ici consiste à utiliser le suivi des modifications.

Premièrement, on peut implémenter des vues qui sont spécifiques à la version dans ce qu'elles consomment, mais en termes de ce qu'elles renvoient, sont uniformes. Par exemple, si Person.Gender existe dans la version 2 mais pas dans la version 1, la vue Personne pour la version 1 peut renvoyer, disons, null pour la version 1.

Pour le consommateur d'entrepôt, ne lisant que les vues, les données ont la même forme (avec une exhaustivité variable).

Le suivi des modifications fournit un moyen (relativement) léger de déterminer quelles données doivent être modifiées à chaque rafraîchissement.

L'implémentation de ce qui précède repose sur un outillage manuel, vous devrez donc être confiant dans le codage SQL et tester des scénarios de performances pour voir à quelle vitesse les incréments prennent pour s'exécuter. Dans de nombreux cas, elles peuvent être inférieures à 1 seconde, mais certaines tables de transactions élevées peuvent générer une charge élevée dans les modifications de traitement. (Le suivi des modifications est «relativement» léger ... seuls les tests le prouvent).

La bonne chose ici, c'est que vous avez un degré élevé de contrôle sur la façon dont les différences de schéma se manifestent, et avec le suivi des modifications, il n'y a aucun risque de problèmes d'intégrité lorsqu'il est implémenté correctement, car le suivi est effectué au niveau du moteur.

Que ce soit vraiment bon pour vous, ce serait difficile à dire.

— Paul Holmes
source