Raccomandazione di architettura che utilizza SQL Server per l'aggregazione e la denormalizzazione in tempo reale

Question

Abbiamo un'applicazione LOB aziendale per la gestione di milioni di record bibliografici (di testo) utilizzando SQLServer (2008). Il database è molto normalizzato (un record completo potrebbe facilmente essere composto da dieci tabelle unite più collezioni nidificate). Le transazioni di scrittura vanno bene, e per ora disponiamo di una soluzione di ricerca molto reattiva, che fa un uso generoso dell'indicizzazione full-text e delle viste indicizzate.

Il problema è che, in realtà, molto di ciò che gli utenti di ricerca devono potrebbero essere meglio serviti da un sola lettura magazzino-tipo di copia dei dati, ma avrebbe bisogno di essere continuamente copiato quasi in tempo reale (la latenza di pochi minuti va bene).

La nostra ricerca è già ottimizzata da più colonne calcolate o tabelle composte e vorremmo aggiungerne altre. Le viste indicizzate non possono coprire tutte le esigenze a causa dei loro vincoli (come nessun join esterno). Esistono dozzine di "aspetti" di questi dati, in modo analogo a un data warehouse di sola lettura che include autorizzazioni, geografia, categoria, qualità e conteggi dei documenti associati. Componiamo anche complesse rappresentazioni xml dei record che sono abbastanza statiche e potrebbero essere composte e archiviate una sola volta.

La quantità totale di denormalizzazione, calcolo e ottimizzazione della ricerca provoca un ritardo inaccettabile se eseguita completamente tramite trigger ed è anche soggetta a conflitti di blocco.

Ho studiato alcuni dei suggerimenti di Microsoft SQL Server e vorrei sapere se qualcuno che abbia esperienza con requisiti simili può offrire consigli dai seguenti tre (o altri suggerimenti che utilizzano lo stack SQL Server/.Net) :

1. replica transazionale a una sola lettura copia - ma non è chiaro dalla documentazione quanto si può cambiare lo schema sul lato abbonato e aggiungere trigger, colonne calcolate o tabelle compositi;

2. partizionamento delle tabelle - non alterare i dati, ma forse per segmento grandi aree di dati che attualmente vengono ricalcolati continuamente, come ad esempio i permessi, tipo di record (60), regione geografica, ecc ... vorrei che permetterà trigger sul lato transazionale per eseguire con meno blocchi?

3. Offline elaborazione batch - Microsoft utilizza quella frase spesso, ma non dà grandi esempi, tranne che per 'il controllo per i segni di frode con carta di credito' sul lato di abbonati di replica transazione ... che sarebbe un grande esempio, ma come si fa esattamente nella pratica? Lavori SSIS eseguiti ogni 5 minuti? Service Broker? Eseguibili esterni che eseguono il polling continuamente? Vogliamo evitare la soluzione 'esegui un processo lungo di notte' e vogliamo anche evitare di bloccare il lato transazionale delle cose eseguendo una routine di aggregazione/compositing ad alta intensità di aggiornamento ogni 5 minuti sul server transazionale.

   • Update per # 3: dopo aver postato, ho trovato this SO answer con un link al Real Time Data Integration mediante il rilevamento delle modifiche, Service Broker, SSIS e fa scattare - sembra promettente - vorrei che essere un percorso consigliato?

   • Un altro aggiornamento: che, a sua volta, mi ha aiutato a trovare rusanu.com - tutte le cose di ServiceBroker da SO utente Remus Rusanu. Le soluzioni di messaggistica asincrona sembrano corrispondere al nostro scenario molto meglio degli scenari di replica ...

Answer 1

tecnologia Service Broker è un bene per servire il vostro compito, anche se ci sono forse potenziale svantaggio a seconda della particolare configurazione del sistema. La caratteristica più preziosa IMO è la capacità di disaccoppiare due tipi di elaborazione: la scrittura e l'aggregazione. Sarai in grado di farlo anche usando diversi database/istanze di SQL Server/server fisici in modo molto affidabile. Ovviamente è necessario dedicare un po 'di tempo alla progettazione del processo di scambio dei messaggi, specificando i formati dei messaggi, pianificando le conversazioni, ecc., Poiché ciò ha un'enorme influenza sulla soddisfazione del sistema risultante.

Ho usato SSBS per il mio compito che era più o meno simile - vicino alla creazione in tempo reale del magazzino di dati analitici basato sul flusso di dati regolare.