Sono sicuro che l'hai visto arrivare, "Dipende".
Dipende da tutto. E la soluzione per condividere i dati dei clienti per il reparto A potrebbe essere completamente diversa per la condivisione dei dati dei clienti con il reparto B.
Il mio concetto preferito che è emerso nel corso degli anni è il concetto di "Eventual Consistency". Il termine deriva da Amazon che parla di sistemi distribuiti.
La premessa è che mentre lo stato dei dati in un'azienda distribuita potrebbe non essere perfettamente coerente ora, "alla fine" lo sarà.
Ad esempio, quando il record di un cliente viene aggiornato sul sistema A, i dati del cliente del sistema B ora sono obsoleti e non corrispondono. Ma, "alla fine", il record di A verrà inviato a B attraverso un processo. Quindi, alla fine, le due istanze corrisponderanno.
Quando lavori con un singolo sistema, non hai "EC", piuttosto hai aggiornamenti istantanei, un'unica "fonte di verità" e, in genere, un meccanismo di blocco per gestire condizioni di gara e conflitti.
Più le tue operazioni sono in grado di lavorare con i dati "EC", più facile sarà separare questi sistemi. Un semplice esempio è un Data Warehouse utilizzato dalle vendite. Usano il DW per eseguire i loro rapporti giornalieri, ma non eseguono i loro rapporti fino al mattino presto e guardano sempre i dati "di ieri" (o precedenti). Quindi non c'è bisogno in tempo reale che il DW sia perfettamente coerente con il sistema operativo quotidiano. È perfettamente accettabile che un processo venga eseguito, ad esempio, alla chiusura dell'attività e sposti nel corso dei giorni transazioni e attività in massa in un'unica operazione di aggiornamento di grandi dimensioni.
Puoi vedere come questo requisito può risolvere molti problemi. Non c'è contesa per i dati transazionali, nessuna preoccupazione che alcuni dati dei rapporti cambieranno nel mezzo dell'accumulo della statistica perché il rapporto ha eseguito due query separate al database live. Non c'è bisogno che le chiacchiere ad alto dettaglio risucchino l'elaborazione della rete e della CPU, ecc. durante il giorno.
Ora, questo è un esempio estremo, semplificato e molto grossolano di EC.
Ma considera un grande sistema come Google. In qualità di consumatore di ricerca, non abbiamo idea di quando o quanto tempo impiega un risultato di ricerca che Google raccoglie fino a quanto è in alto su una pagina di ricerca. 1 ms? 1s? 10? 10 ore? È facile immaginare come se stai colpendo i server della costa occidentale di Google, potresti benissimo ottenere un risultato di ricerca diverso rispetto a quando colpisci i loro server della costa orientale. In nessun momento queste due istanze sono completamente coerenti. Ma in larga misura, sono per lo più coerenti. E per il loro caso d'uso, i loro consumatori non sono realmente interessati dal ritardo e dal ritardo.
Considera la posta elettronica. A desidera inviare un messaggio a B, ma nel processo il messaggio viene instradato attraverso i sistemi C, D ed E. Ciascun sistema accetta il messaggio, si assume la completa responsabilità e quindi lo consegna a un altro. Il mittente vede che l'e-mail viene inviata. Al ricevitore non manca davvero perché non necessariamente sanno che sta arrivando. Quindi, c'è una grande finestra di tempo che può impiegare quel messaggio per passare attraverso il sistema senza che nessuno si preoccupi di sapere o preoccuparsi di quanto sia veloce.
D'altra parte, A avrebbe potuto essere al telefono con B. "L'ho appena inviato, l'hai già ricevuto? Ora? Ora? Ricevilo ora?"
Pertanto, esiste una sorta di livello implicito di prestazione e risposta sottostante. Alla fine, "alla fine", la posta in uscita di A corrisponde alla posta in arrivo di B.
Questi ritardi, l'accettazione di dati obsoleti, siano essi vecchi di un giorno o 1-5, sono ciò che controlla l'accoppiamento definitivo dei tuoi sistemi. Minore è questo requisito, minore è l'accoppiamento e maggiore flessibilità hai a disposizione in termini di design.
Questo è vero fino ai core della tua CPU. Le applicazioni moderne, multi-core e multi-thread in esecuzione sullo stesso sistema, possono avere visualizzazioni diverse degli "stessi" dati, scadute solo di microsecondi. Se il tuo codice può funzionare correttamente con dati potenzialmente incoerenti tra loro, allora Happy Day, si avvia. In caso contrario, è necessario prestare particolare attenzione per garantire che i dati siano completamente coerenti, utilizzando tecniche come la qualifica di memoria volatile o i costrutti di blocco, ecc. Tutto ciò, a modo loro, ha un costo in termini di prestazioni.
Quindi, questa è la considerazione di base. Tutte le altre decisioni iniziano qui. Rispondere a questo può dirti come partizionare le applicazioni tra le macchine, quali risorse sono condivise e come vengono condivise. Quali protocolli e tecniche sono disponibili per spostare i dati e quanto costerà in termini di elaborazione per eseguire il trasferimento. Replica, bilanciamento del carico, condivisioni dati, ecc. ecc. Tutto basato su questo concetto.
Modifica, in risposta al primo commento.
Esatto, esatto. Il gioco qui, ad esempio, se B non può modificare i dati dei clienti, qual è il danno con i dati dei clienti modificati? Puoi "rischiare" che sia obsoleto per un breve periodo? Forse i dati dei tuoi clienti arrivano abbastanza lentamente da poterli replicare immediatamente da A a B. Supponiamo che la modifica venga inserita in una coda che, a causa del basso volume, viene prontamente rilevata (<1s), ma sarebbe comunque "fuori transazione" con la modifica originale, quindi c'è una piccola finestra in cui A avrebbe dati che B non possiede.
Ora la mente inizia davvero a girare. Cosa succede durante quei 1 secondi di "ritardo", qual è il peggior scenario possibile. E puoi progettare intorno ad esso? Se riesci a progettare un ritardo di 1 secondo, potresti essere in grado di progettare un ritardo di 5 secondi, 1 m o anche più lungo. Quanti dati dei clienti utilizzi effettivamente su B? Forse B è un sistema progettato per facilitare il prelievo degli ordini dall'inventario. Difficile immaginare che sia necessario qualcosa di più di un semplice ID cliente e forse un nome. Solo qualcosa per identificare grossolanamente a chi è rivolto l'ordine mentre viene assemblato.
Il sistema di prelievo non deve necessariamente stampare tutte le informazioni sul cliente fino alla fine del processo di prelievo, e a quel punto l'ordine potrebbe essere passato a un altro sistema che forse è più aggiornato, in particolare, con le informazioni sulla spedizione, quindi alla fine il sistema di picking non ha bisogno di quasi nessun dato del cliente. In effetti, potresti INCORPORARE e denormalizzare le informazioni sul cliente all'interno dell'ordine di prelievo, quindi non c'è bisogno o aspettativa di sincronizzare in un secondo momento. Finché l'ID cliente è corretto (che comunque non cambierà mai) e il nome (che cambia così raramente che non vale la pena discuterne), questo è l'unico vero riferimento di cui hai bisogno e tutte le tue schede di prelievo sono perfettamente accurate al momento di creazione.
Il trucco è la mentalità, di scomporre i sistemi e concentrarsi sui dati essenziali necessari per il compito. I dati non necessari non devono essere replicati o sincronizzati. La gente si irrita per cose come la denormalizzazione e la riduzione dei dati, specialmente quando provengono dal mondo della modellazione dei dati relazionali. E con buone ragioni, dovrebbe essere considerato con cautela. Ma una volta che sei stato distribuito, hai implicitamente denormalizzato. Diamine, lo stai copiando all'ingrosso ora. Quindi, potresti anche essere più intelligente al riguardo.
Tutto ciò può essere mitigato attraverso solide procedure e una comprensione approfondita del flusso di lavoro. Identificare i rischi ed elaborare politiche e procedure per gestirli.
Ma la parte difficile è spezzare la catena al DB centrale all'inizio e istruire le persone che non possono "avere tutto" come potrebbero aspettarsi quando si dispone di un unico archivio centrale e perfetto di informazioni.
