buon sistema di database punto di disaccoppiamento?

Question

Abbiamo due sistemi in cui il sistema A invia dati al sistema B. E 'un requisito che ciascun sistema può funzionare indipendentemente dall'altra e nessuno farà saltare se l'altro è basso. La domanda è qual è il modo migliore per sistema A per comunicare con il sistema B mentre soddisfare il requisito disaccoppiamento.

Sistema B ha attualmente un processo che sondaggi dati in una tabella di db ed elabora eventuali nuove righe che sono stati inseriti.

Un progetto proposto è per il sistema A è sufficiente inserire i dati nella tabella db sistema di B ed avere processo di sistema B le nuove righe dal processo esistente. La domanda è fa questa soluzione soddisfa il requisito di disaccoppiare i due sistemi? È una parte del database considerata di un sistema B che potrebbe non essere più disponibile e il sistema di causa A far saltare in aria?

Un'altra soluzione è per il sistema A di mettere i dati in una coda MQ e hanno un processo che avrebbe letto da MQ e quindi inserire nella banca dati del sistema di B. Ma è solo questo overhead in più? In definitiva è una coda MQ più tolleranza d'errore di una tabella db?

Answer 1

In linea generale, la condivisione del database è un accoppiamento stretto e non da preferire se non forse per scopi di velocità. Non solo per scopi di disponibilità, ma anche perché il sistema di A e B saranno cambiati e migliorati in diversi punti nel loro futuro, e dovrebbe avere dipendenze minime a vicenda - Lo scambio di messaggi è una dipendenza evidente, mentre i database condivisi tendono a mordere (o i vostri eredi) sul posteriore quando meno attesi. Se si va il percorso di condivisione del database, almeno rendere l'interfaccia di condivisione esplicita con tavoli dedicati o viste.

Ci sono quattro livelli comuni di integrazione:

1. la condivisione di database
2. La condivisione di file
3. Remote procedure call
4. Message Passing

che può essere applicato e combinati in varie situazioni, con diverse disponibilità e manutenibilità. Hai un'eccellente panoramica al pattern di integrazione enterprise sito .

Come con qualsiasi infrastruttura di integrazione centrale, MQ dovrebbe essere ospitato in un ambiente con grande disponibilità, piena di failover & c. Ci sono altre soluzioni di coda che consentono di distribuire il coordinamento coda.

Answer 2

utilizzare le code per la comunicazione. Non "passare" i dati dal Sistema A del sistema B attraverso il database. Stai usando il database come, costoso, coda di gigante messaggi complesso.

Con una coda di messaggi da una coda di messaggi.

Non si tratta di spese generali "Extra". Questo è il modo migliore per disaccoppiare sistemi. Si chiama Service Oriented Architecture (SOA) e l'utilizzo di messaggi è assolutamente centrale per il design.

Una coda MQ è molto più semplice di un tavolo di DB.

Non confrontare "tolleranza ai guasti", perché un RDBMS utilizza enormi spese generali (quasi inimmaginabili) per raggiungere un livello ragionevole di certezza che la transazione terminata in modo corretto. Bloccaggio. Buffering. Scrivi code. Storage Management. Ecc Ecc.

Un'implementazione coda di messaggi affidabile usa un po 'archivio di backup per mantenere lo stato della coda. L'overhead è molto, molto meno di un RDBMS. La performance è molto meglio. Ed è molto, molto più semplice con cui interagire.

Answer 3

In SQL Server che vorrei fare questo attraverso un pacchetto SSIS o di un lavoro (a seconda del numero di record e la complessità di ciò che mi muovevo). Altri database hanno anche soluzioni ETL. Mi piace la soluzione ETL becasue posso tenere i registri di ciò che è stato cambiato e quali errori sono stati elaborati, posso inviare record che per qualche motivo non andrà all'altro sistema (strutture di dati sono raramente lo stesso tra due basi di dati) a un'azienda tavolo senza uccidere il resto del processo. Posso anche fare modifiche ai dati che scorre per compensare le differenze di database (cose come i valori della tabella di ricerca, dicono lo stato completato nel DB1 è 5 ed è 7 in DB2 o dire DB2 ha un campo obbligatorio che DB1 non e si fa essere necessario aggiungere un valore predefinito alla depositato se è null). Se uno o l'altro servver è giù il lavoro che esegue il pacchetto SSIS fallirà e nessuno dei due sistemi saranno interessati, in modo che mantiene le datbases disaccoppiati come utilizzando i trigger o la replica non sarebbe.