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

Lagring til millioner af billeder

Jeg har i mit liv lavet videodistribution med både S3 (Rackspace cloudfiler inkluderet) og MongoDB.

De fleste mennesker ville uden et andet blik gå efter S3, men jeg har fundet ud af, at begge har deres ulemper. Et af de store problemer er, at S3 ikke er et CDN, det er faktisk et redundant lager inden for en specifik region, der ikke er replikeret til andre S3-regioner, det betyder, at du bliver nødt til at bruge noget som cloudfront oven på S3 for at pinge dine billeder til en slags cache, hvis du skulle få alvorlig belastning på dit websted.

S3 har også andre funktioner, som gør den mindre CDN-agtig og mere til et lagerlager. Når det er sagt, for sjældent tilgåede filer er S3 lynende hurtig.

Dette dobbelte lag skaber naturligvis kompleksiteter såsom vedligeholdelse. Ikke kun det, men et CDN vil fungere på TTL'er, og selvom mange CDN'er nu om dage har kantrensningsevner, er de stadig ikke en 100 % sikker måde at sikre, at dine filer ikke er tilgængelige.

Så på grund af opsætningen og adgangene (mulig adgang til filer, der også bør slettes) kan dette blive ret dyrt ret hurtigt.

Det er her MongoDB kunne vinde. MongoDB kunne, afhængigt af dit scenarie, faktisk være billigere her på grund af det faktum, at du kunne bruge en hel masse mikroforekomster på AWS til rent faktisk at opbevare dine oplysninger, tilføje spot-forekomstreservation til disse forekomster (snavs billigt) og alt hvad du behøver er en stor disk på en enkelt maskine.

For helvede, du kunne endda bruge S3 til at gemme billederne og derefter MongoDB som en cloudfront-erstatning.

Når du vil pinge billeder til forskellige regioner, laver du bare et par spotforekomster i den målregion og får MongoDB til at replikere dataene på tværs. Du kan også lave nogle kool-ting med replikeringen for at sikre, at kun hyppigt tilgåede filer fra den region er placeret i den region.

Så jeg ville ikke smide MongoDB ud (eller endda Cassandra), snarere ville jeg lave en behovstest mellem de to.

Rediger

Som en ekstra bemærkning om S3-priser, hvis du gemmer dine filer i RR (Reduced Redundancy), så halveres prisen (ca.), hvilket gør S3 meget billig, men du har stadig det problem, at S3 ikke er et CDN.

Yderligere redigering

Da jeg egentlig kun fortsatte fra @cirrus' svar, vil jeg faktisk revurdere dit spørgsmål, som er lidt besvaret ovenfor.

Som et eksempel gemmer Youtube faktisk alle deres billeder på enkelte computere, som derefter distribueres, så de nemt kan administrere 200m thumbnails og ... ja ... en masse visninger hver dag nemt fra filsystemet. Så jeg tror, ​​at din bekymring om filsystemet er overvurderet.

Med hensyn til hvilken database der er bedre...Jeg ved det ikke, det kommer ned til din test.

Jeg mener, at svaret på dit problem afhænger af dit scenario og dit budget og din hardware og dine ressourcer, dvs. hvis du har AWS-servere, ville dette være et helt andet svar end dedikerede interne servere.



  1. MongoDB Aggregate Time Series

  2. $elemmatch virker ikke i MongoDB

  3. Mongodb ikke autoriseret på admin til at udføre listDatabases kommando

  4. MongoDB-gruppe efter særskilt sortering sammen