architettura consigliato per la gestione di utente carica immagine

Question

In passato, ho gestito caricamento delle immagini utente in due modi diversi:

• salvare i dati di immagine in una tabella di database, e caricarlo tramite uno script PHP
• Carica l'immagine, convertirla in jpeg, metterlo in una directory e caricarlo tramite tag HTML

la prima opzione ha funzionato abbastanza bene, ma ho dovuto tenere restrizioni di dimensione piuttosto vincolanti sulle immagini caricate. Il secondo tipo di opzione funzionava, fatta eccezione per la libreria di immagini di PHP, spesso comprometteva la conversione dei file (penso che invece sia possibile correggerli usando ImageMagick).

Sono ora di fronte a questa operazione per la terza volta, su una scala potenzialmente più ampia di utenti. Ho già in programma di usare ImageMagick per fare un po 'di post-elaborazione sull'immagine dopo il caricamento. Mi piacerebbe mantenere le restrizioni sul caricamento delle immagini il più possibile ridotte e forse anche conservare tutte le foto caricate da qualcuno.

Ci saranno momenti in cui centinaia di caricamenti di foto dell'utente verranno visualizzati sullo schermo come miniatura in una sola volta. Archiviare questi in un database e trascinarli per ognuno e visualizzarli tramite PHP non sembra un buon modo per andare, ma non è nemmeno il lancio di tutte le immagini in una singola directory.

Qual è il tuo consiglio in questa situazione? Vai con una delle opzioni di cui sopra o hai una soluzione diversa?

Answer 1

Memorizzarle in un database e trascinarle per ognuna e visualizzarle tramite PHP non sembra un buon modo per andare, ma non è nemmeno il lancio di tutte le immagini in una singola directory.

È possibile adottare un approccio ibrido.

Archiviare le immagini in una gerarchia di cartelle (in base allo schema che si ritiene appropriato per l'applicazione). Memorizza il percorso completo per ogni immagine nel tuo database.

In un lavoro in background, avere miniature delle immagini prodotte (ad esempio con ImageMagick) i cui nomi file differiscono leggermente dalle immagini stesse (ad esempio: aggiungi 'thumb-' sul lato anteriore) ma che sono memorizzati accanto alle immagini reali. Puoi avere un campo nel database per ogni immagine che significa "La mia miniatura è pronta, quindi per favore includimi nelle gallerie".

Quando si ottiene una richiesta per una galleria, suddividere e tagliare il gruppo di immagini utilizzando i campi del database, quindi produrre un pezzo di HTML che fa riferimento ai percorsi di anteprima e immagine appropriati.

---

Edit: Cosa Aaron F dice è importante quando è necessario gestire un numero molto elevato di richieste. Il partizionamento dei dati immagine/sql è una buona strada verso la scalabilità. Avrai bisogno di esaminare i pattern di accesso nella tua applicazione per determinare dove si trovano i punti di partizione. Qualcosa che puoi fare ancora prima è memorizzare nella cache l'HTML generato per le gallerie al fine di ridurre il carico SQL.

Answer 2

I due esempi citati non chiariscono la parte più importante: partizionamento.

ad es. se memorizzato in un database, le immagini si trovano interamente in una tabella, su un server di database? O la tabella è condivisa su più server/cluster?

ad es. se memorizzato in una directory, tutte le immagini si trovano su un disco rigido? Oppure le immagini mappano per separare le unità [RAID], in base alla prima lettera nel nome di accesso dell'utente?

Per la scalabilità è necessario un buon schema di partizionamento.

Per quanto riguarda la visualizzazione di miniature in blocco, probabilmente vorrai qualche precomputazione qui. Creare le anteprime (magari tramite un lavoro asincrono, avviato subito dopo il caricamento dell'immagine) e metterle in scena su un server dedicato. Questo è il modo in cui Youtube crea istantanee di immagini dei video caricati.

Answer 3

IMHO, la soluzione di David è il migliore per la maggior parte dei casi, ma vorrei modificare due dettagli:

memorizzare il percorso completo per ogni immagine nel database.

Non credo che è necessario memorizzare il completo percorso, perché se per qualche motivo la directory delle immagini cambiamenti, che complicherebbe la vita un po '. Memorizzare solo il nome del file dovrebbe essere sufficiente. Puoi sempre includere il percorso completo direttamente nell'html.

hanno miniature delle immagini prodotte (ad esempio con ImageMagick) i cui nomi file differiscono leggermente dalle immagini stesse ma sono memorizzate accanto alle immagini reali.

Preferisco mettere le miniature in una directory diversa, una directory per ogni pollice che si crea e con esattamente lo stesso nome di file. Una volta ho lavorato su un sito con migliaia di immagini utente e ho fatto l'errore di metterle tutte nella stessa directory. La directory è cresciuta così tanto che è quasi impossibile aprire questa directory senza dover attendere alcuni minuti.

libreria di immagini PHP Spesso pasticcio la conversione del file

suggerisco di aumentare il limite di memoria nello script in cui si crea il pollice, specialmente se si consente l'upload di file grandi (2MB +).

È possibile farlo con ini_set('memory_limit', '30M');. Certo, il numero attuale dipende da te. 30M ha funzionato per me nei siti di miniature.

Answer 4

uhm per la creazione di miniature, usare phpthumb ... è assolutamente perfetto per quella materia ... e ha alcuni extra, ma probabilmente non ne avrete bisogno ... crea automaticamente una cache locale sul vostro filesystem , quindi è molto risparmio di risorse ...

Penso che l'approccio ibrido è probabilmente il più scalabile, vale a dire memorizza file su file system e posizioni di file in un database ... in questo modo, è possibile memorizzare alcuni metadati con il file (come creatore, titolo, tag, ecc.) e mantieni il tuo database piccolo ... in più puoi archiviare le tue immagini in posizioni arbitrarie (anche su altre macchine, ecc.), così puoi facilmente distribuire tutto quel carico utile ...

greetz

back2dos

Answer 5

Alcuni anni fa ho scritto un archivio di immagini intranet lo scopo di memorizzare in ultima analisi, alcuni 340.000 scansioni più relative miniature.Cercando su Google, ho scoperto che non vi è alcun motivo per non riversarli tutti in una singola directory, purché non si chieda al SO sottostante di fare un elenco di cartelle. In altre parole, la chiamata a ls/dir bloccherebbe la macchina, ma il semplice recupero dei singoli file immagine dal loro nome file (dal database) non comporterebbe alcuna penalizzazione delle prestazioni.

L'archivio è in esecuzione da un paio d'anni e posso confermare che funziona bene con qualcosa sopra le immagini da 60k effettivamente memorizzate in una cartella.

Non ho mai avuto alcun tipo di problema nella conversione di elementi in jpeg con GD, ma per quel particolare lavoro sono andato in ImageMagick con MagicWand come estensione di supporto (principalmente a causa di una documentazione decente).

Answer 6

Vorrei usare la classe Thumbnailer se me lo chiedi.