Sono uno sviluppatore SQL (non DBA o Architect) per un'azienda SaaS di piccole dimensioni (~ 50 dipendenti). Ho il compito di capire come:
- Offload di report operativi dai nostri oltre 100 database OLTP
- Consentire l'esecuzione di tali report su dati provenienti da più database client
- 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.