sql >> Database >  >> NoSQL >> MongoDB

Opslag voor miljoenen afbeeldingen

Ik heb in mijn leven videodistributie gedaan met zowel S3 (inclusief Rackspace-cloudbestanden) als MongoDB.

De meeste mensen zouden zonder een tweede blik voor S3 gaan, maar ik heb ontdekt dat beide hun nadelen hebben. Een van de grote problemen is dat S3 geen CDN is, het is eigenlijk een redundante opslag binnen een specifieke regio die niet wordt gerepliceerd naar andere S3-regio's, dit betekent dat je zoiets als cloudfront bovenop S3 moet gebruiken om je afbeeldingen te pingen naar een soort cache als je je site serieus zou belasten.

S3 heeft ook andere functies waardoor het minder CDN-achtig en meer een opslagmagazijn is. Dat gezegd hebbende, voor weinig gebruikte bestanden is S3 razendsnel.

Deze dubbele laag zorgt natuurlijk voor complexiteiten zoals onderhoud. Niet alleen dat, een CDN werkt ook op TTL's en hoewel veel CDN's tegenwoordig edge-purge-mogelijkheden hebben, zijn ze nog steeds geen 100% zekere manier om ervoor te zorgen dat uw bestanden niet toegankelijk zijn.

Dus door de opzet en de toegangen (mogelijke toegangen van bestanden die ook moeten worden verwijderd) kan dit vrij snel behoorlijk duur worden.

Dit is waar MongoDB kon winnen. MongoDB zou, afhankelijk van uw scenario, hier eigenlijk goedkoper kunnen zijn vanwege het feit dat u een hele reeks micro-instanties op AWS zou kunnen gebruiken om uw informatie daadwerkelijk vast te houden, ter plaatse een instantiereservering toe te voegen aan deze instanties (vuil goedkoop) en alles wat u nodig hebt is een grote schijf op een enkele machine.

Je zou zelfs S3 kunnen gebruiken om de afbeeldingen op te slaan en vervolgens MongoDB als vervanging voor de cloud.

Als u afbeeldingen naar verschillende regio's wilt pingen, maakt u gewoon een paar spotinstanties in die doelregio en zorgt u ervoor dat MongoDB de gegevens repliceert. Je kunt ook wat leuke dingen doen met de replicatie om ervoor te zorgen dat alleen veelgebruikte bestanden uit die regio in die regio worden geplaatst.

Dus ik zou MongoDB niet weggooien (of zelfs Cassandra), maar ik zou liever een inkomenstoets tussen de twee doen.

Bewerken

Als een toegevoegde opmerking over S3-prijzen, als je je bestanden opslaat in RR (Reduced Redundancy), dan halveert de prijs (ongeveer), wat S3 erg goedkoop maakt, maar je hebt nog steeds het probleem dat S3 geen CDN is.

Verder bewerken

Aangezien ik eigenlijk alleen verder ging met het antwoord van @cirrus, zal ik je vraag, die hierboven een beetje is beantwoord, opnieuw evalueren.

YouTube slaat bijvoorbeeld al hun afbeeldingen op afzonderlijke computers op die vervolgens worden gedistribueerd, zodat ze gemakkelijk 200 miljoen miniaturen en ... nou ja ... elke dag gemakkelijk vanuit het bestandssysteem kunnen bekijken. Dus ik denk dat je zorgen over het bestandssysteem overschat worden.

Wat betreft welke database beter is... ik weet het niet, dat komt neer op je testen.

Ik bedoel, het antwoord op je probleem hangt af van je scenario en je budget en je hardware en je middelen, d.w.z. als je AWS-servers hebt, zou dit een heel ander antwoord zijn dan dedicated interne servers.



  1. Wat is het maximale aantal parameters dat wordt doorgegeven aan $in query in MongoDB?

  2. Puntnotatie versus $elemMatch

  3. java.lang.IncompatibleClassChangeError:klasse Mongo implementeren

  4. Transactie 1 is uitgevoerd in MongoDB