implementazione della progettazione per un database postgres in un ambiente non connesso

Question

implementazione della progettazione per un database postgres in un ambiente non connesso

#1 da (1 voti)

0

Ho diversi DB postgres, in siti distanti, due in Cina, 1 in India, uno in Corea, uno in Germania, uno in Francia e uno in Messico.

Tutti i db, indipendentemente dal loro sito, hanno una tabella che fa parte di uno schema. Quella tabella viene aggiornata tramite un foglio di calcolo Excel. Il foglio di lavoro è compilato da una persona fisica.

Joe aggiornerà attraverso il suo spreasheet il tavolo in Corea. Jane aggiornerà il tavolo attraverso il suo spreasheet in India e Dustin e Ahmed, aggiorneranno attraverso il loro spreasheet il tavolo in Cina. E così via per i siti francesi, tedeschi e messicani.

Vogliamo che questi 7 dbs replichino il loro contenuto nel database aziendale principale. La quantità di dati è minuscola, 1 MB al giorno ma in un flusso costante che viene eseguito ora per ora ea volte minuto per minuto, ad esempio 10Kb a 8Am, 200Kb a 9Am e così via.

Vorremmo trasferire i dati non appena Dustin avrà archiviato il foglio di calcolo Excel in Cina nel database aziendale. Come puoi immaginare, dovremo solo copiare i dati dal sito remoto al sito aziendale e non viceversa.

E per ultimo, ma non meno importante, per connettersi alla rete aziendale, il sito cinese o il sito indiano o il coreano e gli altri siti non dispongono attualmente di una connessione VPN (IPSec).

È pgq/londiste , per postgres, una soluzione di replica ottimizzata per impostare la quantità di dati che abbiamo (leggi minuscoli)?
Sarebbe una buona idea una tabella di copia dal sito locale a un db nel cloud come RDS e quindi una copia al db aziendale? Forse è più facile da configurare, ma ho la sensazione di ridondanza qui, anche se probabilmente ci salverà dall'impostare una rotta IPSec.
Se no, quale altra soluzione possiamo usare?
E ultima domanda, dovremmo impostare un ipsec tra il firewall aziendale e il firewall dei siti per consentire la replica?

Grazie

database-development postgres data-replication

posta Andy K 06.06.2017 - 16:37

fonte

1 risposta

Leggi altre domande sui tag database-development postgres data-replication

carica di più e ricerca logica Che tipo di accoppiamento dei parametri è il meno oneroso per il chiamante quando i dati devono essere mappati?

score 1 · Accepted Answer

Il mio suggerimento è di implementare un livello di servizio tra i tuoi umani e il database di ogni sito. Ospita un servizio centrale nella tua rete aziendale principale. Chiedi agli umani di caricare i loro fogli di lavoro sul servizio e lasciare che il servizio controlli come i dati entrano nel database.

Questo ti consente un punto centrale di controllo sui dati.
Non devi occuparti della replica dei dati, puoi semplicemente modificare il servizio per attaccare una riga sia nel database centrale aziendale che nel database fuori sede.
Ti darà il controllo del formato dei dati, ti consentirà di modificare lo schema, convalidare, controllare l'accesso, ecc.
Ha una migliore longevità. Dall'esperienza, gli schemi di replica automatizzati sono difficili da mantenere e monitorare. Sono anche difficili quando si tratta di duplicare dati o unirli.
Non sarà (necessariamente) necessario stabilire una VPN. Puoi semplicemente utilizzare TLS sul tuo servizio con uno schema di autenticazione e autorizzazione appropriatamente sicuro sul tuo servizio.
La latenza tra i dati che non sono sincronizzati sarà molto bassa (millisecondi), dove in uno schema di replica i dati di solito hanno una latenza costante (ad esempio la replica ogni 5 minuti avrà un periodo di 5 minuti in cui i dati non sono sincronizzati). li>
È possibile rimuovere l'accesso umano ai database. Non devi preoccuparti che uno dei tuoi umani cancellerà tutti i tuoi dati. Questo potrebbe anche significare che hai bisogno di meno licenze e puoi risparmiare sui costi (non importante per PostgreSQL)

In precedenza ho lavorato in un'azienda in cui ha implementato un tipo di replica automatica tra molti database MySql e un grande database SqlServer come descritto. Era molto complicato e alla fine lo abbiamo sostituito con un approccio orientato al servizio che ha funzionato molto meglio.