Publish/Subscribe modello in SQL

Question

Background:

Abbiamo un grande tavolo (15+ milioni di euro) di oggetti che viene aggiornato frequentemente durante il giorno (in media 300K variazioni giornaliere). Le modifiche in sospeso sono memorizzate in una tabella di staging e un processo viene eseguito durante il giorno per leggere le modifiche da questa tabella, apportare gli aggiornamenti e contrassegnare le modifiche come elaborate.

Molte altre applicazioni utilizzano i dati nella tabella degli articoli per eseguire varie attività. Spesso, queste attività sono programmate e intensive, poiché implicano il confronto dei dati in tempo reale con le vecchie istantanee e l'aggiornamento di altri sistemi di conseguenza. Ad esempio, elenchiamo gli articoli su eBay e confrontiamo i dati degli articoli in tempo reale con le nostre schede esistenti per vedere se abbiamo bisogno di inserire nuove inserzioni eBay, rimuovere articoli che abbiamo venduto, aggiornare quantità, ecc. Poiché i dati sono così grandi, la maggior parte di queste applicazioni vengono eseguite raramente, lasciando le cose obsolete il più delle volte.

La mia domanda:

Stiamo valutando l'implementazione di un modello di editore/sottoscrittore utilizzando il Service Broker. L'obiettivo sarebbe quello di pubblicare un messaggio quando un elemento cambia, a cui altri sistemi (come la nostra applicazione eBay) possono abbonarsi. Ciò ci consentirebbe di rendere più granulari gli aggiornamenti più vicini al tempo reale, piuttosto che aggiornamenti grandi e poco frequenti che coinvolgono l'interrogazione di tutti i dati, non solo ciò che è cambiato. Tuttavia, dopo aver utilizzato Google, non sembra che questo sia un modello di database comune e che generi bandiere rosse. Questo non è un uso valido di Service Broker (anche se ho trovato una piccola sezione in Pro Sql Server 2008 Service Broker su Pub/Sub)? Come si risolve questo problema normalmente? Sembra un problema abbastanza comune.

TL; DR:

Calcio: Modifica vari sistemi in modo dinamico, ad accoppiamento quando gli elementi singoli cambiano.

Domanda: È stata implementata una soluzione di tipo pub/sub con Service Broker in una soluzione valida in un'impostazione di volume elevato?

Answer 1

Non è un modello di database comune perché la maggior parte dei database relazionali sono malamente attrezzati per farlo fuori dalla scatola. Sql Server sarebbe anche se non avesse Service Broker.

Uno degli sviluppatori di Service Broker talks about how Service Broker handles the challenges that most companies turn to NoSQL solutions for.

E 'la mia comprensione che Service Broker è destinata a fare esattamente quello che stai cercando. Può anche usare External Activation a run custom applications when the data has changed.

Answer 2

Questo è un modello di integrazione molto comune.

Non ho familiarità con SQL Server Service Broker ma se si guarda a qualsiasi stack middleware di integrazione - TIBCO, Oracle, webMethods, Mule, Informatica ecc. - offrono tutti un "adattatore per database" che esegue l'attività che si descrive.

Lo schema generale è che gli aggiornamenti nel database attivano una pubblicazione di messaggi. Ciò avviene tramite un trigger nella tabella del database o tramite l'adattatore "polling" della tabella per i nuovi aggiornamenti. Entrambi i metodi hanno vantaggi e svantaggi.

Il vantaggio principale di questo modello è (come si sospetta) aggiornamenti più frequenti e tempestivi su altri sistemi - un modo più "in tempo reale" di fare business.Inoltre, se si esegue la trasformazione in un formato di messaggio canonico, si ottiene un accoppiamento più flessibile tra i sistemi e quindi meno il dolore quando è necessario modificare/aggiornare i sistemi.

Answer 3

Di solito questo tipo di problemi finisce per diventare più grande (di portata) di quello che può fornire un'implementazione pub/sub focalizzata su database. Se posso fare una raccomandazione, considerare l'utilizzo di un bus di servizio completo in scala:

nServiceBus (gratuito fino a una certa dimensione, passato piuttosto a buon mercato che)

si ottiene un quadro pub/sub solido, ma facile da lavorare con e vi è una vasta base di clienti, articoli e campioni.