Grande quantità di testo: database vs file

Question

Grande quantità di testo: database vs file

#1 da (2 voti)

-1

Ho un'applicazione web con traffico medio-alto in cui gli utenti possono salvare disegni realizzati da fabricjs, quindi ogni progetto salvato è un json con molti parametri.

Quindi, in sostanza, due giorni dopo il lancio, gli utenti hanno memorizzato quasi 300 righe di disegni, PhpMyAdmin dice un totale di 31 MB di dimensioni.

Ogni json è memorizzato come un tipo di dati longtext quindi sono preoccupato per l'aumento della dimensione del database con il tempo.

Ho controllato la funzione COMPRESS MySQL e fatto alcuni test su di esso e la conclusione è che il rapporto di compressione è di circa 30 - 40%, quindi potrebbe essere un po 'basso per quello che voglio ottenere.

Un'altra cosa da sapere è che il processo di salvataggio viene eseguito automaticamente dall'applicazione (questo è un requisito obbligatorio), quindi quando l'utente scarica il disegno come file PNG, il suo json viene automaticamente salvato. Tutti i disegni salvati possono essere proseguiti in qualsiasi momento dall'utente.

Il mio obiettivo è cercare di ridurre al minimo il consumo di spazio nel mio server, è salvare come file system un valida alternativa per minimizzare le dimensioni di MySQL (quindi non penalizzare le prestazioni delle query) o penalizzerebbe i tempi di caricamento della CPU del server con read & scrivere le operazioni sul disco?

database performance mysql file-storage

posta Msam85 24.08.2016 - 00:20

fonte

1 risposta

Leggi altre domande sui tag database performance mysql file-storage

Perché utilizzare le istruzioni using quando si desidera riaprire le connessioni? [chiuso] Nuovo sviluppo del progetto e linee guida e suggerimenti per git [chiuso]

score 2 · Answer 1

Questo è esattamente ciò che è l'ottimizzazione prematura . Fai i conti. 31 MB per due giorni significa 5,5 GB all'anno, ovvero assolutamente niente . Non hai cose più importanti di cui preoccuparti, come, non so, gli indici?

Questo non significa che non si dovrebbe cercare di minimizzare l'utilizzo del disco quando è facile da fare. Hai avuto un'ottima idea per abilitare la compressione: con un solo clic, hai guadagnato il 35%, ovvero da 5,5 GB all'anno, sei ora a 3,6 GB / anno. Non male. Bene, a meno che la compressione non stia uccidendo la tua CPU, il che significa che hai reso la tua app molto più lenta e la tua bolletta elettrica molto più alta.

Tuttavia, altre ottimizzazioni potrebbero non essere così efficaci. La scelta tra l'archiviazione su disco o l'archiviazione nel database, o la scelta tra la compressione di base e alcuni tipi di compressione personalizzata, più potente ma anche più intensiva della CPU, dovrebbe essere eseguita empiricamente, in base ai dati effettivi. Non facendo una domanda agli estranei su un sito Web di Q & A e aspettandoli di indovinare cosa è meglio per te .

Rispetta la soluzione che è facile e immediata da implementare. Quando quella parte dell'applicazione diventerà effettivamente il collo di bottiglia, torna indietro e riprogetta questa parte, confrontando le diverse implementazioni specifiche per il tuo caso. Ad esempio, con un po 'di background, potresti scoprire che l'implementazione dell'archiviazione differenziale JSON rimuoverebbe il collo di bottiglia. Oppure potresti trovare una soluzione diversa dall'osservazione dell'uso effettivo della tua app da parte degli utenti.

Tieni presente che, mentre rinvii la decisione sul luogo in cui i dati verranno effettivamente archiviati, sarai anche incoraggiato a progettare la tua app in modo che le modifiche future siano più facili da eseguire . Se pensi di poter spostare i dati dal database ai file flat, probabilmente sarai anche in grado di migrare più facilmente, ad esempio, su Amazon S3.