Condividi tramite

  • Articolo

Ripartizione del carico di lavoro dell'elaborazione batch

Alcune applicazioni richiedono l'esecuzione di operazioni batch con un elevato carico di elaborazione sui dati. In molti casi non è possibile eseguire tali operazioni sul server OLTP (Elaborazione delle transazioni in linea, OnLine Transaction Processing), in quanto l'overhead di elaborazione interferisce con altre operazioni del server. In questo caso è necessario eseguire l'elaborazione batch su un server separato. In alcuni casi viene semplicemente ripartito il carico di lavoro dell'elaborazione batch. In altri, i risultati del processo batch vengono ripropagati al server di elaborazione in linea.

Nella figura seguente viene illustrato uno scenario tipico con dati replicati a un server di elaborazione batch:

Replica di dati per l'elaborazione in batch

Esempio Adventure Works Cycles

Adventure Works Cycles è un'azienda manifatturiera fittizia utilizzata per esemplificare concetti e scenari relativi ai database. Per ulteriori informazioni, vedere Database di esempio AdventureWorks.

Adventure Works Cycles utilizza l'elaborazione batch per controllare le frodi con carte di credito sul proprio sito Web. I dati raccolti dalle transazioni eseguite nel sito Web vengono replicati dal computer MicrosoftSQL Server che serve il sito Web a un computer SQL Server separato utilizzato per diverse applicazioni Adventure Works Cycles. Sul server di elaborazione batch viene eseguita una ricerca nei dati degli schemi di frode con carte di credito. Sebbene il rilevamento di frodi produca una ridotta quantità di dati (aggiornando i dati in un numero limitato di colonne se per un account viene individuata un'attività sospetta), i controlli richiedono un elevato carico di elaborazione e l'utilizzo di numerose risorse del server. In seguito all'esecuzione del processo batch, una quantità ridotta di dati viene rinviata al server OLTP per il sito Web, indicando gli account per i quali sono stati rilevati possibili indizi di frode.

Requisiti comuni per questo scenario

Le applicazioni di elaborazione batch presentano generalmente i requisiti riportati di seguito, che una soluzione per la replica appropriata deve essere in grado di soddisfare:

  • È necessario che nel sistema venga mantenuta la consistenza delle transazioni.

  • Il sistema deve avere una bassa latenza, in quanto gli aggiornamenti nel server di elaborazione in linea devono raggiungere rapidamente il server di elaborazione batch.

  • 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 della replica deve richiedere un overhead minimo sul server di origine.

  • Le modifiche dei dati possono scorrere in entrambe le direzioni. I risultati dell'elaborazione batch possono infatti essere ripropagati al server di elaborazione in linea.

  • I dati richiesti nel server di elaborazione batch possono essere un subset dei dati disponibili nel server di elaborazione in linea.

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.

  • Nella figura riportata sopra il server di elaborazione in linea è il server di pubblicazione. Nella pubblicazione sono inclusi alcuni o tutti i dati del server di elaborazione in linea e ogni tabella di dati rappresenta un articolo (gli articoli possono essere anche altri oggetti di database, come le stored procedure). Il server di elaborazione batch è un Sottoscrittore della pubblicazione che riceve schema e dati come sottoscrizione.

  • Se i risultati vengono ripropagati al server di elaborazione in linea, il server di elaborazione batch è anche un server di pubblicazione (generalmente con una pubblicazione identica a quella del server di elaborazione in linea) e il server di elaborazione in linea sottoscrive tale pubblicazione.

Per ulteriori informazioni sui componenti del sistema, vedere Panoramica del modello di pubblicazione della replica.

SQL Server supporta diversi tipi di replica per soddisfare differenti esigenze applicative, ovvero la replica snapshot, transazionale e di tipo merge. Per ottenere i migliori risultati, per l'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

Le opzioni da considerare per questo scenario sono il filtro, la replica transazione peer-to-peer e la replica transazionale bidirezionale:

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:

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: