MongoDB
 sql >> база данни >  >> NoSQL >> MongoDB

Съхранение за милиони изображения

През живота си съм правил разпространение на видео както с S3 (включени облачни файлове на Rackspace), така и с MongoDB.

Повечето хора, без втори поглед, биха избрали S3, но открих, че и двата имат своите недостатъци. Един от големите проблеми е, че S3 не е CDN, това всъщност е излишно хранилище в рамките на определен регион, който не се репликира в други S3 региони, това означава, че ще трябва да използвате нещо като cloudfront върху S3, за да пингвате вашите изображения към нещо като кеш, ако искате да натоварите сериозно сайта си.

S3 има и други функции, които го правят по-малко CDN и повече склад за съхранение. Като се има предвид това, за рядко посещавани файлове S3 е светкавично бърз.

Този двоен слой, разбира се, създава сложности като поддръжката. Не само това, но CDN ще работи върху TTL и въпреки че много CDN в момента имат способности за изчистване на граници, те все още не са 100% сигурен начин да се уверите, че вашите файлове не са достъпни.

Така че поради настройката и достъпите (възможни достъпи до файлове, които също трябва да бъдат изтрити) това може да стане доста скъпо доста бързо.

Това е мястото, където MongoDB може печеля. MongoDB може, в зависимост от вашия сценарий, всъщност да бъде по-евтино тук поради факта, че можете да използвате цял куп микроинстанции на AWS, за да съхранявате информацията си, като добавите резервация на спот екземпляри към тези инстанции (много евтино) и всичко, от което се нуждаете е голям диск на една машина.

По дяволите, можете дори да използвате S3 за съхраняване на изображенията и след това MongoDB като заместител на cloudfront.

Когато искате да изпратите ping изображения към различни региони, вие просто правите няколко точкови екземпляра в този целеви регион и карате MongoDB да репликира данните си навсякъде. Можете също така да направите някои интересни неща с репликацията, за да сте сигурни, че само често достъпни файлове от този регион се поставят в този регион.

Така че не бих изхвърлил MongoDB (или дори Cassandra), по-скоро бих направил проверка на средствата между двете.

Редактиране

Като допълнителна бележка относно ценообразуването на S3, ако съхранявате вашите файлове в RR (намалено излишък), тогава цената намалява наполовина (приблизително), което прави S3 много евтин, но все още имате проблема, че S3 не е CDN.

Допълнителна редакция

Тъй като наистина продължих само от отговора на @cirrus, всъщност ще преоценя въпроса ви, на който някак си отговорихте по-горе.

Като пример, Youtube всъщност съхранява всички техни изображения на единични компютри, които след това се разпространяват, така че те могат лесно да управляват 200 милиона миниатюри и... добре... много гледания всеки ден лесно от файловата система. Така че мисля, че притесненията ви относно файловата система са преувеличени.

Що се отнася до това коя база данни е по-добра...не знам, това се свежда до вашето тестване.

Искам да кажа, че отговорът на вашия проблем зависи от вашия сценарий и вашия бюджет, вашия хардуер и вашите ресурси, т.е. ако имате AWS сървъри, това ще бъде съвсем различен отговор от специализираните вътрешни сървъри.



  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Как да съхранявате данни в MongoDb с помощта на mongoose и асинхронен водопаден модел

  2. Невалидна схема, очаква се „mongodb“ или „mongodb+srv“.

  3. Mongo DB отношения между обекти

  4. Mongo MapReduce изберете най-новата дата

  5. Ако имам идентификатор на документ mongo като низ, как да го потърся като _id?