2015-08-25 12 views
5

Diciamo che abbiamo un database per una compagnia di autobus.Archiviazione di record dal database PostgreSQL che superano la timeline

  • Noi raccogliere dati sulle corse di autobus, liste dei passeggeri, carburante ecc
  • Lavoriamo principalmente con i dati sui prossimi giostre
  • A volte abbiamo bisogno di guardare nella storia (per la contabilità), ma il lasso di tempo è breve (3 mesi al massimo).
  • Non vogliamo conservare tutti i record sui nostri server di produzione/sviluppo per ovvi motivi (spreco di memoria, query lente ecc.).
  • Vogliamo avere un database separato dove archiviamo l'intera cronologia.
  • Quale sarebbe il modo migliore per ottenere questo risultato su PostgreSQL?

Siamo alla ricerca di qualcosa di simile:

  • Vogliamo replicare database di produzione (comprese le modifiche di struttura, sequenze ecc)
  • Vogliamo eliminare i vecchi dati dal database di produzione, ma escludere queste dichiarazioni dalla replica per mantenere intatto l'archivio.

Esempio:

  • Quando un viaggio in autobus è più vecchio di 3 mesi, eliminarlo dalla produzione di DB, ma tenerlo in archivio DB, dove già è.

Quello che stiamo attualmente esaminando: (? Slony)

  • Una sorta di replica master/slave.
  • Abilita regola REPLICA per le tabelle specifiche in cui abbiamo emendiamo DELETE/UPDATE con alcune regole di tempo (dove data < NOW() - intervallo di 6 mesi '')

Grazie per le vostre intuizioni.

+1

Considererei un [Wrapper di dati stranieri] (https://wiki.postgresql.org/wiki/Foreign_data_wrappers) con una query eseguita su una pianificazione (cron job o simile). Mantienilo semplice. Meno possibilità di errori o confusione in questo modo. – jpmc26

risposta

0

Questa è un'area in cui la replica logica (qualcosa come Bucardo o Slony) può davvero aiutare, dal momento che è possibile replicare solo i tavoli che si desidera e mantenere i propri trigger attorno ad essi. In questo caso è possibile aggiornare ed eliminare i trigger per archiviare le vecchie versioni dei dati in modo da poterli esaminare.

Ovviamente è possibile farlo anche con i trigger nel database di produzione e quindi utilizzare i wrapper di dati esterni come suggerito dal commento. Ma se stai seguendo questa strada, potresti anche prendere in considerazione la possibilità di copiare in csv e il caricamento in modo da avere un traferro e fare delle trasformazioni se necessario.