MongoDB
 sql >> Database >  >> NoSQL >> MongoDB

Archiviazione per milioni di immagini

Nella mia vita ho distribuito video sia con S3 (inclusi i file cloud Rackspace) che con MongoDB.

La maggior parte delle persone, senza una seconda occhiata, sceglierebbe S3, tuttavia ho scoperto che entrambi hanno i loro lati negativi. Uno dei grossi problemi è che S3 non è un CDN, in realtà è uno storage ridondante all'interno di una regione specifica che non viene replicata in altre regioni S3, questo significa che dovrai usare qualcosa come cloudfront sopra S3 per eseguire il ping delle tue immagini in una sorta di cache se dovessi ottenere un carico serio sul tuo sito.

S3 ha anche altre caratteristiche che lo rendono meno CDN-ish e più un magazzino di archiviazione. Detto questo, per i file a cui si accede raramente S3 è incredibilmente veloce.

Questo doppio strato ovviamente crea complessità come la manutenzione. Non solo, ma una CDN funzionerà su TTL e anche se molti CDN oggigiorno hanno capacità di eliminazione dei bordi, non sono ancora un modo sicuro al 100% per assicurarsi che i tuoi file non siano accessibili.

Quindi, a causa della configurazione e degli accessi (possibili accessi anche a file che dovrebbero essere eliminati), questo potrebbe diventare piuttosto costoso abbastanza rapidamente.

È qui che MongoDB potrebbe vincita. MongoDB potrebbe, a seconda del tuo scenario, essere effettivamente più economico qui a causa del fatto che potresti utilizzare un intero gruppo di micro istanze su AWS per conservare effettivamente le tue informazioni, aggiungendo la prenotazione di istanze spot a queste istanze (a buon mercato) e tutto ciò di cui hai bisogno è un grande disco su una singola macchina.

Diamine, potresti persino utilizzare S3 per archiviare le immagini e quindi MongoDB come sostituto del cloudfront.

Quando si desidera eseguire il ping di immagini in regioni diverse, è sufficiente creare alcune istanze spot in quella regione di destinazione e ottenere MongoDB per replicare i suoi dati. Puoi anche fare alcune cose interessanti con la replica per assicurarti che solo i file a cui si accede di frequente da quella regione siano posizionati in quella regione.

Quindi non butterei via MongoDB (o anche Cassandra), piuttosto farei un test di mezzi tra i due.

Modifica

Come nota aggiuntiva sui prezzi di S3, se memorizzi i tuoi file in RR (Ridondanza ridotta), il prezzo si dimezza (circa) il che rende S3 molto economico, tuttavia, hai ancora il problema che S3 non è un CDN.

Ulteriori modifiche

Dal momento che in realtà ho continuato solo dalla risposta di @cirrus, valuterò nuovamente la tua domanda a cui è stata data una risposta sopra.

Ad esempio, Youtube memorizza effettivamente tutte le sue immagini su singoli computer che vengono poi distribuiti, in modo da poter gestire facilmente 200 milioni di miniature e...beh...molte visualizzazioni ogni giorno facilmente dal file system. Quindi penso che la tua preoccupazione per il file system sia sopravvalutata.

Per quanto riguarda quale database è meglio... non so, questo dipende dai tuoi test.

Voglio dire che la risposta al tuo problema dipende dal tuo scenario e dal tuo budget, dal tuo hardware e dalle tue risorse, ad esempio se hai server AWS questa sarebbe una risposta completamente diversa rispetto ai server interni dedicati.