retroscenaMantenere database in sincronia con le immagini sul file system [PHP/Postgresql/Linux]
Io sostengo e sono nel processo di re-ingegnerizzazione di un paio di PHP applicazioni web based, e non v'è un argomento Mi rifugio Ho trovato una soluzione elegante per ancora, quindi sto cercando qualche input che potrebbe portarmi a un modo migliore per farlo.
STATO ATTUALE
Molti dei miei applicazioni consentono agli utenti di memorizzare le immagini, oltre a un sacco di dati. Tutti i dati finiscono in un cluster PostgreSQL, tuttavia scelgo di non memorizzare le immagini nel database per motivi di prestazioni e manutenibilità. Le immagini ottengono i loro metadati memorizzati nel database (come nome file originale, larghezza/altezza, ecc.) E una volta completata la transazione del database, sposto l'immagine sul filesystem in una directory di immagini (memorizzata come .jpg).
IL PROBLEMA
Tutto questo funziona bene, ma come le applicazioni vengono utilizzati molto, e da più persone simultaniously, e su internet, e la gestione degli errori/eccezioni di PHP non è esattamente la più affidabile in tutti gli scenari, di tanto in tanto sono preoccupato di non essere in grado di memorizzare l'immagine (sul Filesystem) all'interno della transazione del Database (dal momento che si verifica sul filesystem). Sono anche preoccupato perché se un file immagine viene danneggiato/alterato/cancellato sul filesystem, i record del database non verranno aggiornati correttamente (nessuna integrità referenziale).
SOLUZIONI
Quello che mi è venuta in mente finora è:
Opzione A) Conservare l'immagine reale (non solo i metadati, ma l'intero binario) nel database. - Non ne sono entusiasta dato che attualmente il database, pur essendo piuttosto complesso, è ancora molto piccolo (non più di 60 MB di orso). Le immagini correlate ammontano a molti GB, quindi aumenterebbe l'ingombro della mia installazione di PostgreSQL in maniera massiccia. Inoltre, complicherà i miei scenari di backup e replica del database.
Opzione B) Conservare il progetto corrente (immagini su file system, dati in postgres) e cercare semplicemente di tenere conto dei dati corrotti a livello di applicazione in ogni punto in cui vengono utilizzati. - Rende l'applicazione molto più complessa e errorprone. Opzione C) Ho trovato un framework PHP ORM chiamato Flourishlib che contiene una classe di filesystem che simula le transazioni del Filesystem (in pratica se chiamate $ file-> rename() controlla se ciò sarebbe possibile, ma in realtà non rinomina fino a quando si commette la transazione) - Questa è la soluzione migliore che ho trovato finora, tuttavia sto già usando un altro framework ORM (Propel) che mi piace molto di più per un progetto di queste dimensioni, quindi mi richiederei 2 framework con funzionalità sovrapposta.
Era talmente
Quindi, sto pensando molte altre persone qui avranno eseguito in questo stesso "problema" prima, e sono sicuro che alcuni si avvicinò con alcune soluzioni non ho ancora pensato . Apprezzo ogni suggerimento, consiglio o critica.
Ottimizzazione prematura? – symcbean
@symcbean Non proprio, il piano è di ricostruire alcune di queste app da zero, risolvendo molti altri problemi esistenti (le app sono state avviate molto più piccole e sono cresciute costantemente nel tempo, ma l'aggiunta di nuove funzionalità ha degradato la qualità generale). Quindi, dato che lo farò comunque, ha senso (per me comunque) considerare quali altre parti non sono grandi e vedere se c'è un modo migliore per costruirle. – Stackhouse