Alla ricerca di consigli su come integrare i dati da oltre 100 DB client in un database di report centralizzato


10

Sono uno sviluppatore SQL (non DBA o Architect) per un'azienda SaaS di piccole dimensioni (~ 50 dipendenti). Ho il compito di capire come:

  1. Offload di report operativi dai nostri oltre 100 database OLTP
  2. Consentire l'esecuzione di tali report su dati provenienti da più database client
  3. Posiziona la nostra azienda in modo da fornire più soluzioni basate sull'analisi in futuro

Ho letto una serie di articoli su varie tecnologie come la replica transazionale (in particolare il modello di abbonato molti-a-uno / centrale), broker di servizi SQL, log shipping, Change Tracking (CT) e Change Data Capture (CDC, la mia comprensione è questa è solo per le imprese) e non sono sicuro di quale sia la strada migliore da seguire.

Spero che alcuni di voi con esperienza nell'integrazione possano aver incontrato una configurazione simile alla nostra ed essere in grado di indicarmi un percorso di successo o indirizzarmi verso alcune risorse che potrebbero essere utili.

A causa di vincoli di costo, la nostra soluzione deve funzionare in SQL Server Standard Edition. Inoltre, la soluzione deve essere ragionevole da supportare / mantenere all'interno della nostra piccola organizzazione.

Configurazione di base:

Al momento disponiamo di oltre 100 singoli database client, la maggior parte distribuiti su server SQL nel nostro data center, ma alcuni distribuiti su server client all'interno del loro data center in cui è possibile eseguire il remote. Questi sono tutti i database di SQL Server 2008 R2, ma stiamo pianificando di eseguire presto l'aggiornamento a SQL 2016.

Utilizziamo progetti di database e dacpac per garantire che lo schema sia lo stesso in tutti i database client che sarebbero integrati. Tuttavia, poiché non forziamo tutti i client a eseguire l'aggiornamento a nuove versioni contemporaneamente, sono possibili alcune differenze di schema tra gli aggiornamenti. La soluzione deve essere abbastanza flessibile da non interrompersi se il client A è sulla versione 1.0 del software e il client B è sulla versione 1.1.

I report operativi sono attualmente eseguiti direttamente dal database OLTP di ciascun client. Siamo preoccupati per l'impatto che ciò avrà sulle prestazioni dell'applicazione se non lo scarichiamo.

Requisiti di alto livello:

I nostri clienti sono reparti di elaborazione sterili (SPD) ospedalieri che desiderano rapporti aggiornati su ciò che hanno elaborato finora, dove si trova l'inventario, ecc. L'inventario dei processi di SPD tutto il giorno, compresi i fine settimana e le festività. Poiché uno degli scopi principali di questo sforzo è supportare meglio il reporting operativo, vorremmo che i dati fossero il più vicino possibile in tempo reale per continuare a soddisfare le esigenze dei clienti.

Attualmente abbiamo alcuni SPD in database separati che fanno effettivamente parte dello stesso sistema ospedaliero. Questi client vogliono avere la possibilità di segnalare tutti gli SPD nel loro sistema.

In termini strategici, vorremmo la capacità di aggregare facilmente i dati tra tutti i nostri clienti per supportare le nostre iniziative di analisi interne. La nostra aspettativa è che saremo in grado di utilizzare i dati operativi raccolti come fonte per data mart / magazzino.

Pensieri fino ad ora:

La replica transazionale sembra fornire la soluzione più "in tempo reale". Ho trovato questa risposta particolarmente utile, ma sono preoccupato che, con il potenziale per le differenze dello schema, non funzionerà per noi: replica Many-to-One di SQL Server

Il log shipping non sembra ideale dato che il log non può essere ripristinato mentre le query sono attive. O devo eliminare tutti in modo che il registro possa essere ripristinato o che i dati diventino obsoleti. Non sono chiaro se questo metodo possa essere utilizzato per centralizzare i dati da più database, poiché ogni registro spedito sarebbe solo per il singolo database da cui proveniva.

Utilizzando il broker di servizi SQL, la latenza potrebbe essere imprevedibile se una coda non fosse in grado di tenere il passo con il numero di messaggi da elaborare.

CT identifica solo una versione per ogni riga della tabella. La latenza dipenderà dalla velocità con cui potremmo elaborare qualcosa come un pacchetto SSIS rispetto a ciascun database per recuperare i dati e inserirli in un repository centrale.

Dobbiamo prendere in considerazione la replica di ciascun database singolarmente e quindi forse utilizzare una sorta di tecnica di virtualizzazione dei dati per combinare i dati provenienti dalle varie origini replicate?

Qualsiasi consiglio o direzione che sei disposto a fornire sarebbe molto apprezzato.


1
A causa del tuo requisito (quasi) in tempo reale, esaminerei solo l'elaborazione basata sugli eventi con alcune implementazioni della coda dei messaggi (per le garanzie di consegna). Spero che questo aiuti
Grimaldi,

1
Aggiungerei HTAP nel mix. en.m.wikipedia.org/wiki/Hybrid_Transactional/… BIML e SSIS per popolare il negozio comune.
Michael Green,

@Grimaldi, consiglieresti di utilizzare il broker di servizi SQL per implementare le code di elaborazione / messaggi basate sugli eventi o qualche altra tecnologia di messaggistica?
bperry,

Grazie per il suggerimento, @MichaelGreen. Fondamentalmente sembra che HTAP ci consentirebbe di utilizzare i nostri database esistenti sia per OLTP che per OLAP aggiungendo indici columnstore non cluster (NCCI) alle nostre tabelle. Le query dei rapporti utilizzano l'NCCI in modo che non interferiscano con le operazioni transazionali. SQL 2016 include il supporto HTAP in Standard Edition (SE) ma sembra che la cache del columnstore sia limitata a 32 GB nell'intera istanza SQL. Questo potrebbe essere un problema per noi poiché abbiamo dozzine di database nella stessa istanza. microsoft.com/en-us/sql-server/sql-server-2016-editions
bperry

1
Sì columnstore ma anche in memoria, se le specifiche del tuo server ti consentono di andare lì. Ho sentito Sunil Agarwal parlarne recentemente. La regola empirica degli Stati membri era circa il 3% di degradazione dell'OLTP a vantaggio della segnalazione a latenza zero. Purtroppo non ci sono pranzi gratuiti; puoi creare nuove istanze per contenere il DB di report oppure puoi creare una nuova istanza per guadagnare abbastanza margine per supportare HTAP. Non sto sostenendo questo schema. Potrebbe non funzionare per te. Volevo solo farti sapere che esisteva.
Michael Green,

Risposte:


1

Dobbiamo prendere in considerazione la replica di ciascun database singolarmente e quindi forse utilizzare una sorta di tecnica di virtualizzazione dei dati per combinare i dati provenienti dalle varie origini replicate?

Sì. È possibile ospitare più database di abbonati su una singola istanza e quindi interrogarli su di essi con viste o caricarli in un database consolidato.


Esiste un modo più elegante per impostare quelle viste oltre a qualcosa come ... SELECT Field1, Field2, Field3 FROM [Database1]. [Schema]. [TableName] UNION ALL SELECT Field1, Field2, Field3 FROM [Database2]. [Schema ]. [TableName]
bperry

1

Secondo la descrizione sopra riportata, il link ti aiuterà e io lavorerò anche sullo stesso scenario. Editore multiplo con singolo abbonato.

  1. Aggiungi un'altra colonna come server_id con valore predefinito come 1,2,3 e così via e rendila chiave primaria composita.

  2. Quando si creano le pubblicazioni e si aggiungono articoli, la proprietà dell'articolo Azione se il nome è in uso deve essere impostata su Elimina dati. Se l'articolo ha un filtro di riga, elimina solo i dati corrispondenti al filtro. Questo può essere impostato usando la finestra di dialogo Proprietà articolo della procedura guidata Nuova pubblicazione o usando le stored procedure di replica sp_addarticle e specificando un valore di eliminazione per l'argomento @pre_creation_cmd. In questo modo, quando l'abbonato centrale viene inizializzato o reinizializzato da più snapshot di pubblicazione, i dati di snapshot applicati in precedenza verranno conservati poiché verranno eliminati solo i dati corrispondenti alla clausola di filtro.

inserisci qui la descrizione dell'immagine

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


grazie per l'articolo. Utilizzando il modello di abbonato centrale, hai capito come gestirai gli aggiornamenti dello schema dei tuoi editori (ad esempio, con gli aggiornamenti di versione)? Costringerai tutti i database dei publisher a essere aggiornati contemporaneamente? Nel mio ambiente, non abbiamo sempre questa opzione e questa è stata la mia principale esitazione nel perseguire un modello centrale di replica degli abbonati. Se c'è un modo per aggirare questa barriera, mi piacerebbe saperlo!
bperry,

Non sto usando "Aggiorna editore". Ho diviso il database in due parti come (due tipi di replica) parte della tabella nell'editore dettagliato (da editore a abbonato centralizzato) e alcuni è editore principale (abbonato centralizzato a tutti gli editori) .... Anche il mio abbonato centralizzato fa parte del gruppo di disponibilità AlwaysOn per il mio lavoro di replica secondaria come server di report.
Gulrez Khan,

Fammi capire di aver capito la tua soluzione. Supponiamo che Publisher A sia sulla versione 1 e Publisher B sulla versione 2. 1) Hai disattivato la replica delle modifiche dello schema su entrambi i publisher (utilizzando replicate_ddl = 0 al momento dell'installazione). 2) La versione 2 include una nuova colonna, quindi la aggiungeresti manualmente al sottoscrittore centrale. 3) In Publisher B (aggiornato), aggiungere manualmente la nuova colonna nella replica (utilizzando sp_articlecolumn). Non vengono apportate modifiche all'editore A. Ciò consentirebbe ad entrambi gli editori di continuare a replicare al sottoscrittore centrale senza interrompere la replica?
bperry,



1

Una possibile architettura:

Considerare il reporting come una soluzione basata su data warehouse.

In genere un data warehouse è un DB con uno schema che rappresenta il sottoinsieme richiesto dei sistemi di origine. AdventureWorks e AdventureworksDW dimostrano questa modellazione.

Successivamente, ETL: spostamento dei dati dalle origini al data warehouse.

Una possibile implementazione qui è utilizzare il rilevamento delle modifiche.

In primo luogo, è possibile implementare viste che sono specifiche della versione in ciò che consumano, ma in termini di ciò che restituiscono, sono uniformi. es. Se Person.Gender esiste nella versione 2 ma non nella versione 1, la vista persona per la versione uno può restituire, diciamo, null per la versione 1.

Per il consumatore del magazzino, leggendo esclusivamente le viste, i dati hanno la stessa forma (con varia completezza).

Il rilevamento delle modifiche fornisce un modo (relativamente) leggero di determinare quali dati devono essere modificati ad ogni aggiornamento.

L'implementazione di quanto sopra si basa sull'attrezzatura manuale, quindi dovrai essere sicuro della codifica SQL e testare gli scenari delle prestazioni per vedere quanto velocemente gli incrementi richiedono l'esecuzione. In molti casi possono essere inferiori a 1 secondo, ma alcune tabelle di transazioni elevate possono generare un carico elevato nell'elaborazione delle modifiche. (Il rilevamento delle modifiche è "relativamente" leggero ... solo i test lo dimostrano).

La cosa buona qui che hai un alto grado di controllo su come si manifestano le differenze dello schema e con il rilevamento delle modifiche, non c'è alcuna possibilità di problemi di integrità se implementato correttamente, poiché il monitoraggio viene eseguito a livello di motore.

Se questo è sicuramente giusto per te, sarebbe difficile da dire.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.