MongoDB
 sql >> Baza danych >  >> NoSQL >> MongoDB

Przechowywanie milionów obrazów

W swoim życiu zajmowałem się dystrybucją wideo zarówno z S3 (w tym pliki w chmurze Rackspace), jak i MongoDB.

Większość ludzi bez drugiego spojrzenia wybrałaby S3, jednak odkryłem, że oba mają swoje wady. Jednym z największych problemów jest to, że S3 nie jest CDN, jest to w rzeczywistości nadmiarowa pamięć masowa w określonym regionie, która nie jest replikowana do innych regionów S3, co oznacza, że ​​będziesz musiał użyć czegoś takiego jak Cloudfront nad S3, aby pingować swoje obrazy do rodzaju pamięci podręcznej, jeśli Twoja witryna zostanie poważnie obciążona.

S3 ma również inne cechy, które sprawiają, że jest mniej CDN-owski i bardziej przypomina magazyn. Biorąc to pod uwagę, w przypadku rzadko używanych plików S3 jest niesamowicie szybki.

Ta podwójna warstwa oczywiście tworzy komplikacje, takie jak konserwacja. Nie tylko to, ale CDN będzie działać na TTL i chociaż wiele CDN ma obecnie możliwości czyszczenia krawędzi, nadal nie jest to w 100% pewny sposób na upewnienie się, że Twoje pliki nie są dostępne.

Tak więc ze względu na konfigurację i dostępy (możliwe dostępy do plików, które również powinny zostać usunięte), może to dość szybko stać się dość kosztowne.

W tym miejscu MongoDB może wygrać. MongoDB może, w zależności od twojego scenariusza, być tutaj tańszy ze względu na fakt, że możesz użyć całej masy mikroinstancji w AWS, aby faktycznie przechowywać swoje informacje, dodając rezerwację instancji spot do tych instancji (brudnie tanie) i wszystko, czego potrzebujesz to duży dysk na jednym komputerze.

Do diabła, możesz nawet użyć S3 do przechowywania obrazów, a następnie MongoDB jako zamiennika chmury.

Jeśli chcesz pingować obrazy do różnych regionów, po prostu tworzysz kilka wystąpień spot w tym regionie docelowym i pozwalasz MongoDB na replikację swoich danych. Możesz też zrobić kilka rzeczy z replikacją, aby upewnić się, że tylko często używane pliki z tego regionu są umieszczane w tym regionie.

Więc nie wyrzuciłbym MongoDB (ani nawet Cassandry), raczej wykonałbym test środków między nimi.

Edytuj

Jako dodatkowa uwaga na temat cen S3, jeśli przechowujesz pliki w RR (Reduced Redundancy), to cena spadnie o połowę (około), co czyni S3 bardzo tanim, jednak nadal masz problem, że S3 nie jest CDN.

Dalsza edycja

Ponieważ tak naprawdę kontynuowałem tylko od odpowiedzi @cirrus, w rzeczywistości ponownie ocenię twoje pytanie, na które odpowiedź znajduje się powyżej.

Na przykład, Youtube faktycznie przechowuje wszystkie swoje obrazy na pojedynczych komputerach, które są następnie dystrybuowane, dzięki czemu mogą łatwo zarządzać 200-milimetrowymi miniaturami i… cóż… wieloma widokami każdego dnia z łatwością z systemu plików. Więc myślę, że twoje zmartwienie o system plików jest przereklamowane.

Jeśli chodzi o to, która baza danych jest lepsza... nie wiem, sprowadza się to do twoich testów.

Mam na myśli to, że odpowiedź na twój problem zależy od twojego scenariusza i twojego budżetu, twojego sprzętu i twoich zasobów, tj. Jeśli masz serwery AWS, byłaby to zupełnie inna odpowiedź niż dedykowane serwery wewnętrzne.



  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Mongo demon nie działa przez usługę mongod start

  2. Mongodb:wywołanie db.printShardingStatus() / sh.status() w Javie (i JavaScript)

  3. Jak skonfigurować mongodb do usuwania starych plików dziennika?

  4. Konwertuj zapytanie MongoDB na składnię Spring MongoDB

  5. Projekcja listy MongoDB podpola