Service Broker per la BI

Grazie alla (relativa) semplicità nel creare applicazioni asincrone introdotta dal Service Broker, diventa piuttosto interessate provare ad utilizzare un'approcio asincrono in soluzioni dove, ad oggi, non l'avremmo mai provato.

La prima cosa che mi viene in mente è la Business Intelligence. Supponiamo di avere un sito di eCommerce piuttosto grosso e visitato; molto probabilmente avremo due database distinti, un per la gestione delle transazioni online (e quindi ordini, catalogo prodotti, anagrafica utenti, e via dicendo), ed un datawarehouse per lo contenere lo storico di tutte le transazioni e di tutti i dati.

Normalmente l'aggiornamento del datawarehouse viene fatto di notte, tramite processi batch. Questo per diversi motivi, tra cui:

  1. la grande quantità di dati da spostare
  2. la denormalizzazione degli stessi per ottimizzare query di reportistica
  3. l'ottimizzazione del datawarehouse verso la velocità di lettura (quindi, potenzialmente, molti e grossi indici), contrapposta all'ottimizzazione del database OLTP per un buon equilibrio tra letture e scritture (quindi pochi indici e - possibilimente - piccoli, e magari con un fillfactor relativamente basso)

che rendono impraticabile un aggiornamento del datawarehouse in tempo reale, pena un notevole ralletamente delle operazioni OLTP.

Tutto questo però se siamo in un meccanismo sincrono, come il seguente:

BEGIN TRAN

' Inserisco nel db OLTP
INSERT INTO TabellaOrdini VALUES <....>

' Inserisco nel datawarehouse
INSERT INTO TabellaStoricoOrdini VALUES <...>

...

COMMT TRAN

Dove ovviamente la transazione deve aspettare che tutti gli statement insert terminino il proprio lavoro.

Se però utilizziamo il Broker per introdurre e sfruttare un meccanismo asincrono possiamo scrivere quacosa del genere:

BEGIN TRAN

' Inserisco nel db OLTP
INSERT INTO TabellaOrdini VALUES <....>

' invio una notifica di inserimento nel datawarehouse
SEND ON CONVERSATION ..... (@message)

...

COMMT TRAN

Questo approcio permette di rendere asincroni tutti gli aggiornamenti da fare sul datawarehouse e quindi non diventano bloccanti per la transazione online; questo permette inoltre di avere il datawarehouse aggiornata in tempo "quasi-reale", in quanto il Broker è in grado si scalare automaticamente per far fronte anche a molte richieste contemporanee....ed in questo modo i nostri report potranno lavorare su dati il più possibile aggiornati.

Print | posted on martedì 19 luglio 2005 18:18

Feedback

# re: Service Broker per la BI

Left by Marco Russo at 23/08/2005 00:54
Gravatar Davide,
il problema dello scenario che ipotizzi è che difficilmente le trasformazioni sono così "lineari" e spesso coinvolgono richiedono operazioni più o meno complesse e che coinvolgono molte altre tabelle.
Con Analysis Services 2005 lo scenario più realistico è quello di avere una partizione "real-time" che va a prendere i dati giornalieri direttamente dal db OLTP (o da una replica o da un mirror asincrono) integrato a una o più partizioni MOLAP con i dati precedenti; di notte si va a consolidare il tutto su MOLAP. Mentre la partizione real-time ha solo poche dimensioni (es. prodotto/cliente/tempo) l'elaborazione notturna va a rifinire tutti i dettagli (slowly-changing dimension, relazioni many-to-many, dimensioni che richiedono elaborazioni più complesse).
Sinceramente credo che pensare a una trasformazione "real-time" basata su Service Broker sia piuttosto difficile, sia come possibilità realizzativa sia come problematiche implementative; tutt'al più può essere uno degli strumenti da considerare per una piccola e parziale partizione real-time come nello scenario che descrivevo prima.
Comunque, casi reali con Service Broker ne abbiamo ancora molto pochi, è presto per raggiungere conclusioni definitive...
Comments have been closed on this topic.

Copyright © Davide Mauri

Design by Bartosz Brzezinski

Design by Phil Haack Based On A Design By Bartosz Brzezinski