Mogę tutaj odpowiedzieć tylko za MongoDB, nie będę udawał, że wiem dużo o HDFS i innych tego typu technologiach.
Implementacja GridFs jest całkowicie po stronie klienta w samym sterowniku. Oznacza to, że nie ma specjalnego ładowania ani zrozumienia kontekstu obsługi plików w samym MongoDB, w rzeczywistości sama MongoDB nawet nie rozumie, że są to pliki ( http://docs.mongodb.org/manual/applications/gridfs/ ).
Oznacza to, że zapytanie o dowolną część files lub chunks zbieranie spowoduje ten sam proces, co w przypadku każdego innego zapytania, w którym ładuje potrzebne dane do zestawu roboczego ( http://en.wikipedia.org/wiki/Working_set ), który reprezentuje zestaw danych (lub wszystkie załadowanych w tym czasie danych) wymaganych przez MongoDB w określonym przedziale czasowym do utrzymania optymalnej wydajności. Robi to poprzez stronicowanie go do pamięci RAM (dobrze technicznie robi to system operacyjny).
Inną kwestią, którą należy wziąć pod uwagę, jest to, że jest to zaimplementowany sterownik. Oznacza to, że specyfikacja może się różnić, jednak nie sądzę, aby tak było. Wszystkie sterowniki pozwolą Ci na zapytanie o zestaw dokumentów z files kolekcja, która przechowuje tylko metadane plików, co pozwala później wyświetlać sam plik z chunks kolekcja za pomocą jednego zapytania.
Nie jest to jednak ważne, chcesz obsłużyć sam plik, w tym jego dane; oznacza to, że będziesz ładować files kolekcja i jej kolejne chunks kolekcji do swojego zestawu roboczego.
Mając to na uwadze, trafiliśmy już na pierwszy szkopuł:
Czy pliki z gridfs będą buforowane w pamięci RAM i jak wpłynie to na wydajność odczytu i zapisu?
Wydajność odczytu małych plików może być niesamowita, bezpośrednio z pamięci RAM; napisy byłyby równie dobre.
W przypadku większych plików nie. Większość komputerów nie będzie miała 600 GB pamięci RAM i jest całkiem normalne, że mieści się 600 GB partycji pojedynczego pliku na pojedynczym mongod instancja. Stwarza to problem, ponieważ ten plik, aby zostać obsłużony, musi pasować do zestawu roboczego, jednak jest niemożliwie większy niż pamięć RAM; w tym momencie możesz mieć thrashing strony ( http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29 ), przez co serwer po prostu wyświetla błąd strony 24/7, próbując załadować plik. Pisma tutaj również nie są lepsze.
Jedynym sposobem na obejście tego jest rozpoczęcie umieszczania jednego pliku w wielu fragmentach :\ .
Uwaga:jeszcze jedną rzeczą do rozważenia jest to, że domyślny średni rozmiar chunks „fragment” to 256 KB, więc to dużo dokumentów na plik o pojemności 600 GB. To ustawienie można manipulować w większości sterowników.
Co się stanie z gridfs, gdy spróbuję napisać kilka plików jednocześnie. Czy będzie jakaś blokada operacji odczytu/zapisu? (Będę używać go tylko jako przechowywania plików)
GridFS, będąc tylko specyfikacją, używa tych samych blokad, co w każdej innej kolekcji, zarówno odczytu, jak i zapisu na poziomie bazy danych (2.2+) lub na poziomie globalnym (przed wersją 2.2). Te dwa elementy również kolidują ze sobą, tj. jak zapewnić spójne czytanie dokumentu, do którego jest pisany?
Biorąc to pod uwagę, istnieje możliwość rywalizacji w oparciu o specyfikę scenariusza, ruch, liczbę jednoczesnych zapisów/odczytów i wiele innych rzeczy, o których nie mamy pojęcia.
Może istnieją inne rozwiązania, które mogą skuteczniej rozwiązać mój problem?
Osobiście stwierdziłem, że S3 (jak powiedział @mluggy) w formacie o zmniejszonej redundancji działa najlepiej, przechowując jedynie część metadanych o pliku w MongoDB, podobnie jak przy użyciu GridFS, ale bez zbierania porcji, pozwól S3 obsłużyć całą tę dystrybucję, tworzenie kopii zapasowych i inne rzeczy dla Ciebie.
Mam nadzieję, że wyraziłem się jasno, mam nadzieję, że to pomoże.
Edycja:w przeciwieństwie do tego, co przypadkowo powiedziałem, MongoDB nie ma blokady na poziomie kolekcji, jest to blokada na poziomie bazy danych.
