SQL Data Sync

A cosa e quando serve

Questo articolo tratta solo in parte le tematiche tecniche, prende invece in considerazione un sistema di replica dal punto di vista progettuale e della sua utilità. A cosa serve un sistema di replica? Fa davvero al caso mio? Come può migliorare la mia infrastruttura e come lo posso applicare al mio lavoro quotidiano? Di cosa devo tener conto?

Queste sono alcune delle domande alle quali cercheremo di dare una risposta in questo articolo.

Cos'è un sistema di replica SQL

È facilmente intuibile che un sistema di replica SQL si basa sulla sincronizzazione e quindi replica dei dati fra una o più istanze di database.

Questa è naturalmente una ipersemplificazione. Ciò che invece dobbiamo sapere è che alla base di questo concetto c'è: la necessità di replicare le informazioni contenute in uno o più database, dislocati in infrastrutture e luoghi differenti.

La tecnologia base prevede che, una volta configurato, il sistema replichi sincronizzando ad intervalli regolari dati totali o parziali su tutte le istanze coinvolte. In questo modo è dunque possibile creare una struttura: distribuita, ridondata e consistente.

Esistono diversi tipi di replica i quali offrono prestazioni, funzionalità e sicurezza a livelli differenti. Prima però di implementare questa utile tecnologia è importante capire quale utilizzo se ne dovrà fare. Un sistema di replica presenta delle sfaccettature, non meno importanti, che vanno anch'esse analizzate fin dalle fasi di strartup progettuale.
Il che ci porta a porci le prime domande: è possibile sincronizzare solo una parte di database? quale volume ha il database da sincronizzare? La mia connettività Aziendale potrebbe risentirne? Quali sono le best practices a livello di sicurezza? Cosa è Necessario a livello di infrastruttura? Meglio cloud, on-premises o misto?

Queste sono solo alcune delle domande base che dovremo porci prima di addentrarci negli aspetti più "tecnici" di sviluppo.

Altro concetto fondamentale della replica SQL è quello dei ruoli.
Esiste un server (o istanza) publisher distributor e uno subscriber, ed esistono fra di loro ruoli e realazioni che hanno privilegi differenziati in funzione alla tipologia di utilizzo.
Un po' il concetto di master e slave dove gli agenti (replication agents) lavorano a livello server per garantire la massima efficenza nella gestione dei dati e dell'infrastruttura.

Gli agenti, come appena accennato, hanno ruoli e compiti differenti in base alla tipologia di replica utilizzata (transactional, merge, snapshot etc.). Questo è uno degli aspetti chiave per la gestione di un sistemi di replica SQL, poichè consente la sincronizzazione e gestione dei dati e e degli oggetti di database, senza l'ausilio di ulteriori strumenti rispetto a quelli server side.
Un vantaggio non da poco quando l'obiettivo è implementare soluzioni scalabili e performanti.

Ecco dunque un primo concetto semplice:
Un sistema di replica è in grado di distribuire e sincronizzare dati ed oggetti che siano: totali, parziali identici o eterogenei senza l'ausilio di ulteriori application server rispetto a quelle native.
In questo modo è possibile realizzare strutture: scalabili, ridondante, altamente disponibili, distribuite e altamente performanti.

Tipi di replica (in sintesi)

Esistono diverse tipologie di replica SQL. Generalmente il primo approccio è sempre quello server to server di tipo transazionale ma non è l'unico e nemmeno il più efficente. Come sempre quello davvero efficente è quello calibrato sulle reali necessità e sulle reali possibilità dell'infrastruttura disponibile.

Pensiamo ad esempio ad un'Azienda che deve esporre il proprio listino prezzi all'interno dell'area riservata del proprio sito internet manetenndolo costantemente aggiornato. In questo caso una replica di tipo transazionale ci consentirà di mantenere i dati aggiornati su entrambi gli ambienti senza che debbano essere utilizzati altri strumenti rispetto a quelli già inclusi nel database SQL.
In pratica le persone continueranno a lavorare all'interno del propriuo ambiente aziendale e nel frattempo aggiorneranno il listino online.

Prima di procedere dovremo comunque fare alcune valutazioni ad esempio sulla dimensione del database Aziendale.
In un sistema ERP  "vale" diversi GB se non TB. Molto spesso all'interno si trovano dati storici di ogni genere: contabili, anagrafiche clienti e prodotti, fatture, DDT e tutto quello che riguarda la gestione ordinara del lavoro quotidiano di anni.

Se dovessimo sincronizzare tutti i dati e gli oggetti oltre che inutile, risulterebbe estremamente impegnativo e costoso.
I dati necessari al nostro scopo in realtà sono solo una piccola parte. Non servono nemmeno quelli storici.
Una replica selettiva di tipo transazionale in questo caso sarà più che sufficiente.  

Ecco di seguito le principali modalità nelle quali è possibile effettuare una replica SQL:

1. Replica Transazionale
   Da un database all'altro in tempo quasi reale in una direzione.
   
   
2. Di tipo Merge
   Dati aggiornati in entrambe le direzioni (chi pubblica e chi sottoscrive) con controllo di coerenza.
   
   
3. Snapshot
   Blocco di un momento specifico e invio di tutto il pacchetto al sottoscrittore in un'unica soluzione. Comodo soprattutto all'inizio.
   
   
4. Peer-to-Peer
   La versione transazionale veloce per più server sottoscrittori. Ottima per reti geolocalizzate.
   
   
5. Transazionale Bidirezionale
   Utile quando si devono acquisire, su più istanze, pubblicazioni di dati. Pensate ad esempio alla borsa: io ti aggiorno su queste azioni tu su quelle entrambi pubblichiamo realtime le informazioni.
   
   
6. Sottoscrizioni aggiornabili
   Un po' come le trasnazioni bidirezionali con il vantaggio che un sottoscrittore con dati più aggiornati, può avvisare il pubblicatore dell'aggiornamento, il quale a sua volta aggiornerà di conseguenza tutti gli altri sottoscrittori.

Ecco dunque le principali tipologie di replica SQL utilizzate.
Dobbiamo poi tener conto che esistono altri metodi per sincronizzare dati e database eterogenei su reti differenziate .

Dipende dunque sempre dalle nostre esigenze e dalla nostra infrastruttura. Driver ODBC, JDBC, Web service CData Sync e altre applicazioni che possono fare al caso nostro quando due o più database sono differenti.

Ad esempio: per sincronizzare i dati fra un database MySql e uno SQL, un applicativo che si interfaccia con i driver ODBC è una soluzione comune, stabile ed efficente.

Se invece la replica è prevista solo fra istanze SQL, il sistema nativo è sicuramente il più efficace. 

Ed ecco un parametro davvero fondamentale:
Per stabilire quale tipo di replica ci serve dobbiamo dunque aver tracciato quale sarà il flusso logico delle informazioni da sincronizzare e quali dovranno essere i relativi ruoli nell'operazione di sincronizzazione.

A cosa e a chi serve

Un sistema di replica SQL ha moltissime applicazioni pratiche.
Negli ultimi anni l'avvento delle tecnologie dedicate alla system integration hanno aperto, in tal senso, possibilità di sviluppo in ogni settore produttivo. Basti pensare ad esempio: all'IoT, ai big data, all'e-commerce, alle transazioni finanziarie, ai dati geolocalizzati, all'interconnessione fra dispositivi mobili e infrastrutture differenziate solo per citare alcuni dei modelli di sviluppo.

Intendiamoci: queste tecnologie funzionano anche senza la replica SQL ed esistono sistemi alternativi che garantiscono ottimi risultati. Troviamo però che la sua applicazione pratica nelle infrastrutture di buon livello offrà, in particolari ambiti, risultati interessanti.

Come GRK l'abbiamo applicata e la applichiamo in varie situazioni, principalmente dove abbiamo la necessità di sincronizzare solo ed esclusivamente i dati in contesti che devono mantenere un livello di performance molto alto.

Un esempio classico è quello dell'e-commerce:

Abbiamo da una parte un sistema CMS con un catalogo strutturato che ha la necessità di recuperare informazioni quali:

1. Listini
   
   
2. Anagrafiche articoli
   
   
3. Anagrafiche clienti
   
   
4. Destinazione delle spedizioni
   
   
5. Logiche di Pricing

Dall'altro un sistema ERP on-premises collocato in una struttura Aziendale tradizionale che deve recuperare realtime:

1. Nuove anagrafiche
   
   
2. Dettagli sugli ordini
   
   
3. Dettagli sullo scarico del magazzino

Dovendo mantenere i dati sempre sicnronizzati ed aggiornati fra le due infrastrutture, soprattutto per quanto riguarda ordini e magazzino, una replica di tipo Merge fra due database è un sistema semplice e performante e che non richiede ulteriori applicativi se non l'agente SQL base.

Chiaro, bisognerà fare una verifica a livello di infrastruttura. Ad esempio se è facile trovare un database SQL all'interno di un'Azienda, è più raro all'interno di una soluzione Hosting classica.

In questo caso potrà aiutarci Azure la soluzione Cloud di Microsoft che offre molti strumenti di integrazione fra i quali i sistemi di replica SQL.

È inoltre un ottimo sistema per bilanciare i benefici fra necessità e costi, oltre a garantire una migliore sicurezza sulla protezione dei dati e la salvaguardia della banda internet Aziendale.

Ecco un altro parametro:
La replica SQL consente di distribuire le risorse per evitare di sovraccaricare un sistema. Rendendo di fatto la struttura più flessibile e agile.

Conclusioni

La replica SQL non è qualcosa che è possibile o che vale la pena di implementare in tutti gli ambiti.
Ad esempio: se abbiamo un sito o una web app molto semplice ed un budget limitato ci sono altri sistemi che è meglio utilizzare. Ad esempio sulle integrazioni i web service sono uno standard sicuro e funzionale. Ma se state progettando una struttura che deve: manetere i dati aggiornati su più istanze di database, distribuire servizi e ruoli, implementare in modo scalabile nuovi servizi e avete a che fare con una struttura che cresce e crescerà a livello funzionale, la replica SQL è senza dubbio qualcosa da prendere in considerazione.