Memorizzazione di immagini nel file system e ritorno di URL o ridimensionamento e restituzione virtualmente di array di byte?

Naviga le tue risposte
4

Devo creare un servizio web REST per gestire le immagini inviate dall'utente e mostrarle tutte in un sito web. Esistono più siti Web che utilizzeranno questo servizio per gestire e visualizzare le immagini. I requisiti devono avere 5 dimensioni dell'immagine predefinite disponibili.

Le 2 opzioni che vedo sono le seguenti:

  1. Il servizio Web creerà le 5 immagini, le memorizzerà nel file system e memorizzerà gli URL nel database quando l'utente invia l'immagine. Quando viene richiesta l'immagine, il servizio Web restituirà un array di URL.

    Vedo questa opzione essere un po 'dura sul disco rigido. Le stime sono 10.000 utenti per sito e diciamo, 100 siti. L'elaborazione pesante verrà eseguita quando l'utente invia l'immagine e ogni immagine verrà estratta dal File System.

  2. Il servizio Web memorizzerà solo l'immagine che l'utente invia nel file system e il suo URL nel database. Quando l'utente richiede immagini, il servizio Web otterrà le informazioni dal DB, caricherà l'immagine in memoria, creerà le sue 5 istanze e restituirà un oggetto con 5 array di immagini (probabilmente memorizzerò gli array nella cache).

    Questa opzione è più difficile sul processore e sulla memoria. L'elaborazione pesante verrà eseguita quando vengono richieste le immagini.

    Un plus che vedo per l'opzione 2 è che mi darà la possibilità di riscrivere l'URL dell'immagine e renderlo dipendente dal sito (più carino) di avere un repository di immagini per tutti i siti web. Ma questo non è un grosso problema.

Cosa ne pensi di queste opzioni? Hai altri suggerimenti?

    
posta ismaelf 20.03.2012 - 00:07
fonte

2 risposte

1

Utilizzare sicuramente un archivio file, che sia un CDN classico, uno nuvoloso o un roll-your-own. Inoltre non mi preoccuperei di memorizzare tutte le 5 dimensioni dell'immagine. Crea le immagini ridimensionate al volo, al primo accesso (ovvero se la query DB per una determinata immagine e dimensione restituisce NULL per l'URL, ridimensiona l'immagine più grande e restituisce l'URL appena creato, quindi memorizzalo per riferimenti futuri ).

Non preoccuparti troppo dei dischi rigidi. C'è già una cache di file molto efficace in ogni sistema operativo pertinente, e avrai difficoltà a batterlo. Inoltre, avresti intenzione di servire un milione di utenti. Puoi citare spazio di archiviazione a un ragionevole $ 1,00 per utente e avere un sacco di soldi con cui giocare.

Non preoccuparti della bellezza dell'URL. Il nostro filestore è noto come download.<OurCompanyName>.com , anche se in realtà è ospitato da una nota società di CDN.

    
risposta data 20.03.2012 - 14:33
fonte
2

Preferisco ospitarli su server di immagini e collegarli a loro dai database. I database non sono molto abili nel gestire enormi blocchi.

Ad esempio, se stavi usando la suite AWS, direi mantieni i tuoi dati (fino a 64kb) in DynamoDB e metti l'immagine reale in S3. (Puoi usare CDN se la distribuzione geografica / enorme disponibilità è necessaria). A seconda del tuo database, troverei una soluzione di questo tipo.

E sì - assicurati che la FS sia disponibile come S3, e che tu abbia pensato anche alla persistenza / backup a lungo termine di questi. Quando il db viene ripristinato / ripristinato, il file system deve essere ripristinato nello stesso punto, altrimenti vedrai bug molto strani. Questo è molto più difficile da implementare nella pratica, se pensi di costruire questo negozio da solo.

    
risposta data 20.03.2012 - 02:13
fonte

Leggi altre domande sui tag

Utilizzo di un meccanismo di back-end per copiare i file su DB e notificare l'applicazione Che cosa ottieni quando attraversi un numero a precisione multipla con un numero a virgola mobile?