Scalabile di archiviazione Immagine

Question

Al momento sto progettando un'architettura per un'applicazione web-based che dovrebbe anche fornire un qualche tipo di memorizzazione delle immagini. Gli utenti saranno in grado di caricare le foto come una delle caratteristica fondamentale del servizio. Anche la visualizzazione di queste immagini sarà uno degli usi primari (via web).

Tuttavia, non sono sicuro di come realizzare un tale componente di memorizzazione delle immagini scalabile nella mia applicazione. Ho già pensato a diverse soluzioni, ma a causa di esperienze mancante, non vedo l'ora di sentire i vostri suggerimenti. A parte le immagini, anche i metadati devono besaved. Qui sono i miei primi pensieri:

1. Usa un (distribuito) file system come HDFS e preparare server web dedicati come "clienti" del file system al fine di salvare le immagini caricate e le richieste di servizio. meta dati di immagine vengono salvati in un database aggiuntive, tra cui le informazioni percorsofile per ogni immagine.

2. Utilizzare un sistema BigTable-oriented come HBase sulla parte superiore della HDFS e salvare immagini e metadati insieme. Ancora una volta, server web caricamenti ponticello e richieste.

3. Utilizzare un database completamente schemaless come CouchDB per la memorizzazione di entrambe le immagini e metadati. Inoltre, utilizzare la stessa base di dati per il caricamento e delievery utilizzando l'API RESTful HTTP-based. (Ulteriori domanda: CouchDB non salvare blob tramite Base64 Si può comunque restituire i dati in forma di image / jpeg, ecc.)?

Answer 1

Ci sono state utilizzando CouchDB per questo, salvare le immagini come "Allegato". Ma dopo un anno i file di database GB CouchDB multi-dozzina si è rivelato essere un mal di testa. Per esempio la replica di CouchDB ha ancora problemi, se lo si utilizza con dimensioni molto grandi documenti.

Così abbiamo appena riscritto il nostro software per utilizzare CouchDB per informazioni sulle immagini e Amazon S3 per la memorizzazione delle immagini reali. Il codice è disponibile presso http://github.com/hudora/huImages

Si potrebbe desiderare di istituire un servizio di archiviazione compatibile con Amazon S3 sul posto per il vostro progetto. In questo modo si mantiene flessibile e lascia l'opzione amazon senza la necessità di servizi esterni per ora. Walruss sembra diventato il più popolare e scalabile clone S3.

Vi esorto anche di esaminare la progettazione di Livejournal con la loro eccellente Open Source MogileFS e < a href = "http://www.danga.com/perlbal/" rel = "noreferrer"> offerte Perlbal . Questa combinazione è probabilmente l'immagine più famosa al servizio di installazione.

Anche il flickr Architettura può essere una fonte di ispirazione, anche se non offrono software Open Source per la pubblico, come Livejournal fa.

Answer 2

"Ulteriori domanda:. CouchDB fa risparmiare blob tramite Base64"

CouchDB non salvare blob come Base64, sono memorizzati in formato binario dritto. Durante il recupero di un documento JSON con ?attachments=true noi convertiamo il binario su disco per Base64 al fine di aggiungere in modo sicuro a JSON, ma che è solo una cosa livello di presentazione.

Allegati Standalone .

CouchDB serve allegati con il tipo di contenuto che vengono memorizzati con, è possibile, infatti comuni, in HTML del server, CSS e gli allegati GIF / PNG / JPEG direttamente al browser.

Gli allegati possono essere in streaming e, in CouchDB 1.1, anche sostenere l'intestazione Range (per lo streaming media e / o la ripresa di un download interrotto).

Answer 3

Seaweed-FS (si chiamava Weed-FS), un'implementazione di carta pagliaio di Facebook .

Seaweed-FS è molto flessibile e abita in fondo ai principi fondamentali. E 'stato creato per memorizzare miliardi di immagini e servirli veloce.

Answer 4

Avete considerato Amazon Web Services? S3 è di archiviazione di file basato sul web, e SimpleDB è un chiave-> negozio attributo. Entrambi sono performante e altamente scalabile. E 'più costoso di mantenere il proprio server e configurazioni (supponendo che si sta andando a fare da soli e non assumere persone), ma si ottiene installato e funzionante molto più rapidamente.

Modifica:. Lo prendo di nuovo - la sua più costoso nel lungo periodo ad alto volume, ma per volume basso batte il costo iniziale di acquisto di hardware

S3: http://aws.amazon.com/s3/ (è possibile memorizzare file qui la tua immagine, e per le prestazioni magari avere una cache immagine sul vostro server, o forse no)

SimpleDB: http://aws.amazon.com/simpledb/ (metadati potrebbe andare qui: immagine mappatura id a tutto ciò che i dati che si desidera memorizzare)

Modifica 2: Io non sapevo nemmeno di questo, ma c'è un nuovo servizio web chiamato cloudfront ( http://aws.amazon.com/cloudfront/ ). E 'per la consegna di contenuti web veloce, e si integra bene con S3. Un po 'come Akamai per le vostre immagini. Si potrebbe utilizzare questo invece di cache dell'immagine.

Answer 5

Usiamo MogileFS. Siamo gli utenti di piccole dimensioni con meno di 8 TB e circa 50 milioni di file. Siamo passati da immagazzinare in Amazon S3 alcuni anni fa, per ottenere un migliore controllo dei nomi di file e le prestazioni.

Non è il software più bella, ma è molto "testati sul campo" e in fondo tutti gli utenti lo utilizzano allo stesso modo vi sarà.

Answer 6

Forse avere uno sguardo alla descrizione di Facebook pagliaio

ago in un pagliaio: efficiente stoccaggio di miliardi di foto

Answer 7

Come parte del Cloudant, non voglio spingere prodotto .... ma BigCouch risolve questo problema nella mia domanda pila scienza (fisica - niente a che fare con Cloudant, e certamente nulla a che fare con il profitto). Si sposa la semplicità del design CocuhDB con l'auto-sharding e scalabilità che manca in single-server di CouchDB. Io in genere uso per memorizzare un numero minore di file di grandi dimensioni (multi-GB) e un gran numero di file di piccole dimensioni (100 MB o meno). Stavo usando S3 ma i costi di ottenere effettivamente iniziare ad aggiungere fino a piccoli file che vengono ripetutamente accessibili.

Answer 8

Ok, se tutta quella roba AWS non è andare a lavorare, qui ci sono un paio di pensieri.

Per quanto riguarda la (3), se si mette i dati binari in un database, gli stessi dati sta per venire fuori. Ciò che lo rende un JPEG è il formato dei dati, non ciò che il database pensa che sia. Ciò che rende il client (browser) pensa che la sua un jpeg è quando si imposta l'intestazione Content-type a image/jpeg. Si potrebbe anche impostarlo su qualcos'altro (non raccomandato), come il testo ed è così che il browser avrebbe cercato di interpretarlo.

Per la memorizzazione su disco, mi piace CouchDB per la sua semplicità, ma HDFS sarebbe certamente lavorare. Ecco un link ad un post di servire il contenuto dell'immagine da CouchDB: http://japhr.blogspot.com/2009/04/render-couchdb-images-via-sinatra.html

Modifica:. Ecco un link ad una discussione utile sulla memorizzazione nella cache immagini in memcached vs servendoli da disco sotto Linux / Apache

Answer 9

Ho avuto modo di sperimentare con alcune delle funzionalità _update disponibile per la visualizzazione dei server CouchDB in mio assistente vista Python.

Una cosa davvero cool ho fatto è stata una funzione di aggiornamento per il caricamento di immagini in modo che potessi usare PIL per creare le miniature e altre immagini correlate e collegarli al documento quando vengono spinti al CouchDB.

Questo potrebbe essere utile se avete bisogno di manipolazione delle immagini e si desidera ridurre la quantità di codice e delle infrastrutture è necessario tenere il passo.

Answer 10

Ho scritto negozio immagine sulla parte superiore del cassandra. Abbiamo un sacco e scrive e casuale legge lettura / scrittura è basso. Per elevato rapporto di lettura / scrittura vi consiglio di MongoDB (GridFS).

Answer 11

Ecco un esempio per memorizzare un'immagine blob in CouchDB utilizzando PHP laravel. In questo esempio, sto memorizzazione di tre immagini in base alle esigenze degli utenti.

Realizzazione del collegamento in CouchDB.

$connection = DB::connection('your database name');

/*region Fetching the Uers Uploaded Images*/

$FirstImage = base64_encode(file_get_contents(Input::file('FirstImageInput')));
$SecondImage =base64_encode(file_get_contents(Input::file('SecondImageInput')));
$ThirdImage = base64_encode(file_get_contents(Input::file('ThirdImageInput')));

list($id, $rev) = $connection->putDocument(array(
    'name' => $name,
    'location' => $location,
    'phone' => $phone,
    'website' => $website,
    "_attachments" =>[
        'FirstImage.png' => [
            'content_type' => "image/png",
            'data' => $FirstImage
        ],
        'SecondImage.png' => [
            'content_type' => "image/png",
            'data' => $SecondImage
        ],
        'ThirdImage.png' => [
            'content_type' => "image/png",
            'data' => $ThirdImage
        ]
    ],
), $id, $rev);

...

stesso è possibile memorizzare una sola immagine.