Controllo delle versioni di un set di dati in un RDBMS utilizzando iniziali e delta

Question

Sto lavorando a un sistema che rispecchia i set di dati remoti utilizzando iniziali e delta. Quando arriva un'iniziale, massa cancella qualsiasi cosa preesistente e massa inserisce i nuovi dati. Quando arriva un delta, il sistema fa un sacco di lavoro per tradurlo in aggiornamenti, inserimenti ed eliminazioni. Le iniziali e i delta vengono elaborati all'interno di lunghe transazioni per mantenere l'integrità dei dati.

Sfortunatamente la soluzione attuale non si adatta molto bene. Le transazioni sono così grandi e di lunga durata che il nostro RDBMS si blocca con vari problemi di contesa. Inoltre, non esiste una buona traccia di controllo per come vengono applicati i delta, rendendo difficile la risoluzione dei problemi che causano la mancata sincronizzazione delle versioni locale e remota del set di dati.

Un'idea è quella di non eseguire affatto le iniziali e le delta nelle transazioni e invece di allegare un numero di versione a ciascun record che indichi da quale delta o iniziale proviene. Una volta caricati con successo un iniziale o un delta, l'applicazione può essere avvisata della disponibilità di una nuova versione del set di dati.

Questo lascia solo il problema di come comporre esattamente una vista di un set di dati fino a una data versione dall'iniziale e dai delta. (TimeMachine di Apple fa qualcosa di simile, utilizzando hard link sul file system per creare una "vista" di un certo momento.

Qualcuno ha esperienza nella risoluzione di questo tipo di problema o nell'implementazione di questa particolare soluzione?

Grazie!

Answer 1

Grazie a chi ci ha provato.

Per chiunque altro finisca qui, sto valutando una soluzione che aggiunge una colonna "dataset_version_id" e "dataset_version_verb" a ciascuna tabella in questione.Una sottoquery correlata all'interno di una stored procedure viene quindi utilizzata per recuperare il dataset_version_id corrente durante il recupero di record specifici.Se l'ultima versione del record ha dataset_version_verb di "delete", i risultati vengono filtrati da una clausola WHERE.

Finora questo approccio ha una media di circa l'80% delle prestazioni, il che potrebbe essere accettabile per i nostri scopi.

Answer 2

ha un database di scrittore e diversi lettori.Invia la scrittura a un database e fai in modo che propaghi le stesse identiche modifiche a tutti gli altri database.I database del lettore saranno eventualmente coerenti e il tempo per l'aggiornamento è molto veloce.L'ho visto fare in ambienti che ottengono più di 1 milione di visualizzazioni di pagina al giorno.È molto scalabile.Puoi persino mettere un router hardware davanti a tutti i database letti per bilanciarli.