Progettazione, latenza e backlog coerenti
Un set di replica è coerente quando le query SQL su un nodo di replica del gruppo producono lo stesso risultato su tutti i nodi di replica del gruppo. Per mantenere identici i database su nodi diversi, IBM® Netezza® Replication Services utilizza il metodo eventually consistent.
Con il metodo eventualmente coerente, può capitare che un nodo (il primario) abbia contenuti del database più recenti rispetto agli altri. La quantità di tempo di cui la replica è in ritardo rispetto al primario è chiamata latenza e la quantità di dati che devono essere replicati e applicati dalla replica è il backlog.
La latenza e il backlog dipendono dalla configurazione specifica e dal carico di lavoro. Le cause specifiche della latenza in IBM Netezza Replication Services sono le seguenti:
- La capacità dei nodi primari di eseguire transazioni di aggiornamento SQL (che includono, ad esempio, INSERT, DELETE o UPDATE) contro i dati replicati in parallelo è soggetta ai livelli di isolamento delle transazioni correnti (che possono essere serializzabili o snapshot isolation). Le repliche eseguono le transazioni replicate in modo seriale nell'ordine in cui sono state impegnate sul primario. Il tempo necessario per completare un insieme di transazioni replicate concorrenti sul primario è equivalente al tempo impiegato dalla transazione più lunga. Tuttavia, il tempo necessario per completare le stesse transazioni su una replica è la somma dei tempi di esecuzione di ciascuna transazione.
- I dati del file di carico vengono replicati agli host di replica dopo che sono stati caricati completamente sul primario. Tutti i dati del file di carico vengono prima acquisiti completamente nel registro del gestore delle code della replica primaria, quindi i dati vengono trasmessi alla replica. Solo quando tutti i dati di una transazione sono stati trasferiti completamente, la replica inizia ad applicare i dati. Il tempo di trasferimento del registro di replica è dato dalla quantità totale di dati divisa per la larghezza di banda limitata della connessione del gestore della coda di replica e contribuisce direttamente alla latenza. Per più carichi sequenziali nella stessa transazione, IBM Netezza Replication Services non attende che tutti i carichi siano completati prima di iniziare il trasferimento; la latenza cade tra il tempo di trasmissione dell'ultimo carico di grandi dimensioni e il tempo di trasmissione di tutti i dati.
Il design coerente ha implicazioni per le applicazioni che utilizzano IBM Netezza Replication Services per implementazioni su larga scala. Alcune considerazioni sulla progettazione sono le seguenti:
- Le query che devono essere eseguite con latenza zero devono essere emesse sul primario corrente. Il primario corrente può essere identificato dalle viste operative del set di replica.
- Le applicazioni che eseguono query che devono essere eseguite con una bassa latenza controllano le viste operative del set di repliche per determinare la latenza corrente delle repliche e quindi inviano le query alle repliche la cui latenza rientra nei limiti accettabili.
- Le query che non sono sensibili alla latenza possono essere inviate a qualsiasi nodo NPS del set di replica.
- È possibile progettare le query in modo da utilizzare i dati di riga, come la data, l'ora, l'esecuzione del batch o altri valori di colonna identificativi, per escludere i risultati più recenti di un determinato valore.