sql >> Databasteknik >  >> NoSQL >> MongoDB

Lagring för miljontals bilder

Jag har i mitt liv distribuerat video med både S3 (Rackspace-molnfiler ingår) och MongoDB.

De flesta människor, utan en andra blick, skulle gå för S3 men jag har upptäckt att båda har sina nackdelar. Ett av de stora problemen är att S3 inte är ett CDN, det är faktiskt en redundant lagring inom en specifik region som inte replikeras till andra S3-regioner, det betyder att du måste använda något som molnfront ovanpå S3 för att pinga dina bilder till en sorts cache om du skulle få allvarlig belastning på din sida.

S3 har också andra funktioner som gör den mindre CDN-aktig och mer av ett lagringslager. Som sagt, för sällsynta filer är S3 blixtsnabb.

Detta dubbla lager skapar naturligtvis komplexitet som underhåll. Inte bara det, utan ett CDN kommer att fungera på TTL:er och även om många CDN:er nu för tiden har kantrensningsförmåga är de fortfarande inte ett 100 % säkert sätt att se till att dina filer inte är tillgängliga.

Så på grund av installationen och åtkomsterna (möjliga åtkomster till filer som också bör raderas) kan detta bli ganska dyrt ganska snabbt.

Det är här MongoDB kunde vinna. MongoDB kan, beroende på ditt scenario, faktiskt vara billigare här på grund av det faktum att du kan använda en hel massa mikroinstanser på AWS för att faktiskt behålla din information, lägga till platsförekomstreservation till dessa instanser (smutsbilligt) och allt du behöver är en stor disk på en enda maskin.

Helvete, du kan till och med använda S3 för att lagra bilderna och sedan MongoDB som en molnfrontsersättning.

När du vill pinga bilder till olika regioner gör du bara några få platsinstanser i den målregionen och får MongoDB att replikera sin data över. Du kan också göra några bra grejer med replikeringen för att se till att endast ofta åtkomliga filer från den regionen placeras i den regionen.

Så jag skulle inte kasta ut MongoDB (eller ens Cassandra), snarare skulle jag göra ett behovstest mellan de två.

Redigera

Som en extra notering om S3-prissättning, om du lagrar dina filer i RR (Reduced Redundancy) så halveras priset (ungefär) vilket gör S3 väldigt billig, men du har fortfarande problemet att S3 inte är ett CDN.

Ytterligare redigering

Eftersom jag egentligen bara fortsatte från @cirrus svar kommer jag faktiskt att omvärdera din fråga som är lite besvarad ovan.

Som ett exempel, Youtube lagrar faktiskt alla sina bilder på enstaka datorer som sedan distribueras, så att de enkelt kan hantera 200 m miniatyrer och ... ja ... många visningar varje dag enkelt från filsystemet. Så jag tror att din oro för filsystemet är överskattad.

Vad gäller vilken databas som är bättre...Jag vet inte, det beror på dina tester.

Jag menar att svaret på ditt problem beror på ditt scenario och din budget och din hårdvara och dina resurser, d.v.s. om du har AWS-servrar skulle detta vara ett helt annat svar än dedikerade inhouse-servrar.



  1. MapReduce aggregering baserat på attribut som finns utanför dokumentet

  2. Nodejs paginering

  3. Syntax saknas; före uttalande i mongoexport

  4. MongoDB $min