Miglioramento della scalabilità
Nelle applicazioni di livello intermedio spesso viene utilizzato un unico database per l'archiviazione dei dati e questo aspetto può causare limitazioni della scalabilità in caso di database di grandi dimensioni. Se le applicazioni eseguono prevalentemente operazioni di lettura anziché di scrittura, ad esempio un catalogo basato sul Web, è possibile scalare in orizzontale la porzione di lettura del carico di lavoro tramite il caching dei dati di sola lettura tra più database e impostando le connessioni dei client ai database in maniera uniforme per distribuire il carico.
Nella figura seguente viene illustrata una configurazione in cui l'applicazione e i server Web utilizzano dati da qualsiasi server di cache tra i tre disponibili.
.gif "Utilizzo della replica come soluzione di scalabilità per le attività di lettura")
Se l'applicazione richiede inoltre una maggiore disponibilità e/o che le operazioni di lettura e aggiornamento per un determinato utente vengano indirizzate a uno specifico server applicazioni e quindi a uno specifico server di cache, vedere l'esempio in Miglioramento della scalabilità e della disponibilità.
Esempio Adventure Works Cycles
Adventure Works Cycles è un'azienda manifatturiera fittizia utilizzata per esemplificare concetti e scenari relativi ai database. Per ulteriori informazioni, vedere Esempi e database di esempio.
Il sito Web di Adventure Works Cycles è stato recentemente aggiornato per includere le nuove funzionalità seguenti:
- Ordinazione di prodotti in linea per i clienti.
- Verifica in linea dello stato dell'ordine.
- Capacità di ricerca avanzate nella documentazione del prodotto.
La possibilità di ordinare prodotti in linea dal sito Web incrementa notevolmente l'attività dell'unico computer dell'azienda dedicato a Microsoft SQL Server. Gli amministratori di Adventure Works decidono di utilizzare questo computer come origine di dati replicati. Tutte le attività di lettura vengono scalate a tre computer aggiuntivi che eseguono SQL Server e che eseguono il caching dei dati ottenuti dal computer di origine. I computer di cache gestiscono tutte le attività di lettura, incluse le operazioni di esplorazione e ricerca del catalogo prodotti e di verifica dello stato dell'ordine eseguite dagli utenti. Tutte le attività di lettura vengono indirizzate al database di origine.
Requisiti comuni per questo scenario
Le applicazioni che utilizzano la replica per migliorare la scalabilità in genere presentano i requisiti seguenti, che devono essere presi in considerazione da una soluzione di replica appropriata:
- È necessario che nel sistema venga mantenuta la consistenza delle transazioni.
- La latenza del sistema deve essere bassa, poiché gli aggiornamenti eseguiti nell'origine devono raggiungere rapidamente la cache.
- La velocità effettiva del sistema deve essere elevata, perché il sistema deve essere in grado di gestire la replica di un numero elevato di transazioni.
- L'elaborazione delle repliche deve causare un overhead minimo sull'origine.
- I dati richiesti nella cache possono essere un subset dei dati disponibili nell'origine.
Tipo di replica da utilizzare per questo scenario
In SQL Server viene utilizzata una metafora basata sul settore dell'editoria per la descrizione dei componenti del sistema di replica. I componenti includono il server di pubblicazione, Sottoscrittori, pubblicazioni, articoli e sottoscrizioni. Per ulteriori informazioni sui componenti del sistema, vedere Panoramica del modello di pubblicazione della replica.
Nella figura sopra riportata l'origine è rappresentata dal server di pubblicazione. I dati disponibili nell'origine vengono inclusi in parte o interamente nella pubblicazione e ogni tabella di dati costituisce un articolo (gli articoli possono inoltre essere altri oggetti di database, come le stored procedure). Ogni cache è un Sottoscrittore della pubblicazione che riceve schemi e dati sotto forma di sottoscrizione.
SQL Server supporta diversi tipi di replica per soddisfare diverse esigenze applicative, ovvero la replica snapshot, transazionale e di tipo merge. Per ottenere i migliori risultati nell'implementazione di questo scenario, è consigliabile utilizzare la replica transazionale, essendo la più appropriata per la gestione dei requisiti descritti nella sezione precedente. Per ulteriori informazioni sulla replica transazionale, vedere Panoramica della replica transazionale e Funzionamento della replica transazionale.
Le caratteristiche di progettazione tipiche della replica transazionale la rendono il tipo di replica ideale per soddisfare i requisiti principali di questo scenario:
- Consistenza delle transazioni
- Bassa latenza
- Velocità effettiva elevata
- Overhead minimo
La principale opzione da valutare per questo scenario è il filtraggio dei dati. La replica transazionale consente di filtrare le colonne e le righe, pertanto le tabelle nei Sottoscrittori contengono solo i dati richiesti dall'applicazione. Per ulteriori informazioni, vedere Applicazione di filtri ai dati pubblicati.
Passaggi per l'implementazione dello scenario
Per l'implementazione di questo scenario, è innanzitutto necessario creare una pubblicazione e le sottoscrizioni, quindi inizializzare ogni sottoscrizione. Fare clic sui collegamenti seguenti per ulteriori informazioni su ogni passaggio:
- Configurazione della distribuzione
- Pubblicazione di dati e oggetti di database
- Sottoscrizione delle pubblicazioni
- Inizializzazione di una sottoscrizione
Dopo l'inizializzazione della sottoscrizione e l'attivazione del flusso di dati tra il server di pubblicazione e i Sottoscrittori, potrebbe essere utile consultare gli argomenti seguenti per raccogliere ulteriori informazioni sulle attività più comuni di amministrazione e monitoraggio:
- Monitoraggio della replica
- Strategie per il backup e il ripristino della replica snapshot e della replica transazionale
- Risoluzione dei problemi relativi alla replica
- Rimozione della replica
Vedere anche
Altre risorse
Replica di dati in un ambiente da server a server