Esiste un'app libreria universitaria online in cui molti studenti possono acquistare libri. Ogni volta che uno studente effettua l'accesso, mostra un elenco di suggerimenti in base alla cronologia degli acquisti precedenti. L'SQL Server che archivia i dati dei clienti si trova a Seattle, ma questi studenti accedono da tutto il mondo. Pertanto, le prestazioni potrebbero risentirne e coloro che sono più lontani sulla WAN potrebbero riscontrare un ritardo per le query.
Invece di fare in modo che gli studenti più lontani subiscano tempi di caricamento delle pagine lenti, la replica può essere utilizzata per copiare e mantenere oggetti di database in più siti e sincronizzarli in un secondo momento in modo da mantenere la coerenza. Ciascun sito conserva la porzione del database che contiene i dati per loro più rilevanti e più frequentemente utilizzati. Ora, ogni studente può acquistare libri sul sito Web e i dati verranno sincronizzati in seguito.
Come funziona la replica dei dati
Esistono diversi componenti del server e assumono ruoli diversi per implementare la replica. Un ruolo di editore è un'istanza di database in cui risiede l'origine dei dati e contiene oggetti progettati come articoli di replica. Questi articoli sono raggruppati e pubblicati in una pubblicazione in modo che i dati vengano replicati come un'unità. L'editore può avere più pubblicazioni.
Un ruolo di distributore è un'istanza di database che contiene i database di distribuzione. Ogni editore viene mappato su un singolo database di distribuzione che archivia i dati replicati dall'editore che deve essere passato al sottoscrittore. Il distributore può essere impostato come distributore locale, il che significa che una singola istanza del server può svolgere i ruoli sia dell'editore che del distributore. Se un distributore è configurato su server separati, viene definito distributore remoto.
Un ruolo di abbonato è l'istanza o le istanze che ricevono i dati replicati sottoscrivendo le pubblicazioni. L'abbonato non è limitato ed è idoneo a ricevere dati da più editori e gli oggetti possono essere aggiornati a seconda del tipo di replica. Se applicabile, l'editore riceverà queste modifiche dall'abbonato e ripubblicherà i dati.
In generale, l'abbonato riceve le modifiche ai dati in due modi:tramite sottoscrizione push o sottoscrizione pull. La differenza è in quale componente del server esegue gli aggiornamenti. Con il push, il distributore spinge o aggiorna direttamente il database degli abbonati. Con pull, l'abbonato effettua il check-in con il distributore per vedere se sono state apportate modifiche ed eseguirà l'aggiornamento stesso.
Tre tipi di replica dei dati
Per implementare la replica, vengono utilizzati diversi agenti per eseguire i lavori associati alla copia delle modifiche, alla registrazione delle modifiche e alla distribuzione dei dati. Gli agenti necessari dipendono dal tipo di replica utilizzata. Esistono tre tipi principali di replica.
1. Replica di istantanee
La replica snapshot è il tipo più semplice di replica dei dati e viene utilizzata se i dati non vengono modificati con la stessa frequenza o se è necessario replicare piccoli volumi di dati. Ad esempio, se ci sono tabelle che non vengono aggiornate molto, è possibile utilizzare gli agenti snapshot per copiare l'intero database una o più volte in base a una pianificazione. Quindi, un agente di distribuzione è responsabile del trasferimento di questi file all'abbonato.
Questa tecnica richiede poca manutenzione perché ciò che viene distribuito è un'istantanea dei dati in un momento specifico. Inoltre, non è necessario monitorare le modifiche perché ogni volta che un abbonato riceve un aggiornamento, sovrascrive l'intera copia dei dati.
Sfortunatamente, la copia di un intero database può contribuire a una latenza elevata oa più attese del previsto. La generazione di snapshot richiede il mantenimento di blocchi sugli oggetti. Non è conveniente se i dati vengono modificati spesso e probabilmente influiscono sulle prestazioni, ad esempio se l'editore ha molte attività di inserimento, aggiornamento ed eliminazione.
Oltre a utilizzare gli agenti snapshot per creare gli snapshot, le repliche transazionali sfruttano anche gli agenti di lettura log eseguiti presso il distributore. L'agente di lettura log legge i registri delle transazioni del database dell'editore e fornisce solo le modifiche contrassegnate invece di attendere su un intero database. Ciò fornisce flessibilità perché ti dà spazio per decidere la quantità di database da pubblicare (ad esempio, una colonna). Quindi, l'agente di distribuzione sposta le transazioni agli abbonati e dove viene eseguito ospiterà rispettivamente le strategie di sottoscrizione push e pull.
2. Replica transazionale
La replica transazionale standard implica che i dati dell'abbonato siano di sola lettura. Tuttavia, esistono diversi tipi di pubblicazione che consentono di apportare modifiche all'abbonato. Se queste modifiche vengono apportate, possono essere ritrasmesse all'editore per la ripubblicazione. L'agente di lettura della coda viene utilizzato per la replica transazionale bidirezionale e leggerà le modifiche dalla coda e le applicherà all'editore.
La replica transazionale è molto vantaggiosa in un ambiente da server a server in cui è possibile apportare modifiche in tempo reale all'editore e all'abbonato, ad esempio i dati in tempo reale relativi ai voli attualmente disponibili per una compagnia aerea. In questo caso non ha senso utilizzare la replica degli snapshot perché gli aggiornamenti vengono in genere sincronizzati una volta al giorno o in base a una pianificazione.
3. Unisci replica
La replica di tipo merge è come la replica di transazione, ma consente di unire gli aggiornamenti sia dell'abbonato che dell'editore. Molti abbonati possono andare offline, aggiornare i dati in momenti diversi, quindi tornare online e sincronizzare le modifiche in un secondo momento.
È probabile che questo tipo di replica venga utilizzato in ambienti da server a client come i client mobili. Come lo snapshot e la replica delle transazioni, lo snapshot iniziale viene creato dall'agente snapshot, ma poi l'agente di merge terrà traccia delle modifiche e risolverà i conflitti con i trigger. Se più abbonati stanno aggiornando le stesse righe, possono causare un problema. Pertanto, la risoluzione dei conflitti deve essere presa in considerazione.
