Refactoring lontano dal modello di Database condiviso

Question

Al lavoro, abbiamo diverse applicazioni con database in un server SQL centralizzato. Ogni volta che un'applicazione deve funzionare con i dati di un'altra applicazione, la interroga o la aggiorna tramite il database. Credo che questo sia il modello "Database condiviso" come descritto nel libro Modelli di integrazione aziendale (Hohpe & Woolf).

Queste dipendenze del database incrociato ci stanno causando molti, molti mal di testa. Il più grande di questi al momento è che stiamo incontrando problemi di prestazioni sul server SQL e non è possibile scalare a causa delle dipendenze tra database. Penso che ciò che dovremmo fare è spostarci dallo schema del Database condiviso verso un sistema di messaggistica come descritto nel libro EIP. Ogni applicazione sarebbe responsabile di tutti i propri dati e altre app che vorranno accedere a tali dati otterrebbero i servizi (su un bus di messaggistica?).

• Da dove iniziare il refactoring verso il modello di messaggistica?
• Iniziamo con il refactoring di una delle applicazioni per gestire il proprio database dell'applicazione?
• Quindi le altre applicazioni sono attualmente integrate con quella attraverso il database?
• È questo il modo migliore per disaccoppiare le nostre dipendenze del database o dovremmo iniziare da qualche altra parte?

Answer 1

Suggerirei una transizione a 3 fasi.

1. Aggiungere un livello di messaggistica a ciascuna delle applicazioni.
2. Modificare tutto l'accesso ai dati cross-application per utilizzare il livello di messaggistica appena creato.
3. Ridimensionare i database (ora indipendenti) secondo necessità.

Inoltre, supponiamo di avere 3 applicazioni; A, B e C.

Si potrebbe anche vedere questo come 3 transizioni separate:

• applicazione A

  • Aggiungi Messaging alla A
  • Change chiamate a un in B & C

• Applicazione B

  • Aggiungi Messaging a B
  • Change chiamate a B in A & C

• Applicazione C

  • Aggiungi Messaging al C
  • Change chiamate a C in A & B

A questo punto del processo i risultati sono gli stessi della fine della fase 2 e la fase 3 può procedere. La differenza è semplicemente se è più produttivo concentrarsi su un tipo di refactoring o concentrarsi su un'applicazione.

Answer 2

I messaggi possono sicuramente essere uno dei modi più eleganti per andare. Tuttavia, richiede anche un po 'di lavoro e dovrà cambiare nel tempo ogni volta che cambia ogni database. Abbiamo adottato l'approccio "più semplice" semplicemente facendo in modo che ogni applicazione sappia come accedere all'altro database e quindi eseguire query su ciascun database da lì. Abbiamo scoperto che la maggior parte delle query su database incrociati sono piuttosto leggere e quindi non rappresentano una base di codice sostanziale nella seconda app. C'è qualche duplicazione di query selezionate, ma è stato meno lavoro di quanto sarebbe stato un sistema di messaggistica.

Tutto dipende dal grado in cui spingerete e trascinerete i dati. Se è sostanziale, la messaggistica è il modo migliore per andare. Se è minimo, forse una semplice nuova connessione all'altro database è una strada da percorrere.

Answer 3

Vorrei anche considerare come le applicazioni utilizzano il database. In genere un database (entrambi di progettazione & implementazione) dovrebbe rientrare in una delle due diverse categorie: transazionale (OLTP) o reporting (OLAP).

Un database transazionale ben progettato (e implementato) dovrebbe fornire prestazioni eccellenti in uno scenario di applicazione Line-Of-Business tipico; allo stesso modo, un database di report ben progettato (e implementato) dovrebbe fornire prestazioni eccellenti quando si interrogano grandi quantità di complessità dei dati.

Un'altra importante distinzione è la differenza tra "tempo reale" e "quasi in tempo reale".

Supponiamo che le varie applicazioni debbano eseguire entrambe le operazioni transazionali (in tempo reale) e alcuni rapporti su dati attuali/precedenti; avrete bisogno di due archivi dati: uno transazionale costruito esclusivamente per la velocità operativa per supportare le operazioni 'in tempo reale' delle applicazioni, e un altro che contiene dati 'storici' che verranno costruiti esclusivamente per il reporting.

Il trucco è quindi determinare la quantità di dati che è necessario conservare nell'archivio dati transazionale e quando/come spostarlo nell'archivio dati di reporting.