Czy GridFS jest wystarczająco szybki i niezawodny do produkcji?

86

Tworzę nową witrynę internetową i chcę używać GridFS jako miejsca do przechowywania wszystkich plików przesyłanych przez użytkowników, ponieważ oferuje wiele zalet w porównaniu do normalnego przechowywania w systemie plików.

Benchmarki z GridFS obsługiwanym przez nginx wskazują, że nie jest on tak szybki jak normalny system plików obsługiwany przez nginx.

Benchmark z nginx

Czy jest ktoś, kto korzysta z GridFS już w środowisku produkcyjnym lub użyłby go do nowego projektu?

Railsmechanic
źródło
1
Wpis na blogu dotyczący przechowywania obrazów w mongodb dla przyszłych wyszukiwarek, którzy mieli podobny zamiar co ja: menge.io/2015/03/24/storing-small-images-in-mongodb (porównuje GridFS z wrzuceniem go do dokumentu jako binarny data)
Decydując się na przechowywanie danych binarnych w MongoDB, należy wziąć pod uwagę wiele kompromisów - patrz: alexmarquardt.com/2017/03/02/…
Alexander Marquardt,

Odpowiedzi:

118

Używam gridfs w pracy na jednym z naszych serwerów, który jest częścią strony porównującej ceny z honorowymi statystykami ruchu (około 25 000 odwiedzających dziennie). Serwer nie ma dużo pamięci RAM, 2 gigabajty, a nawet procesor nie jest zbyt szybki (Core 2 duo 1,8 GHz), ale serwer ma dużo miejsca: 10 TB (sata) w konfiguracji raid 0. Zadanie wykonywane przez serwer jest bardzo proste:

Każdy produkt w naszej porównywarce cen ma obraz (według naszej bazy danych jest około 10 milionów produktów), a zadaniem serwerów jest pobranie obrazu, zmiana jego rozmiaru, zapisanie go w gridfs i dostarczenie do przeglądarki odwiedzających. .. jeśli nie ma go w siatce ... lub ... dostarcz go do przeglądarki odwiedzających, jeśli jest już zapisany w siatce. Można to więc nazwać „tradycyjnym schematem cdn”.

Przechowaliśmy i przetworzyliśmy 4 miliony obrazów na tym serwerze od momentu jego uruchomienia. Zmiana rozmiaru i przechowywanie odbywa się za pomocą prostego skryptu php ... ale na pewno skrypt w Pythonie lub coś takiego jak java może być szybsze.

Aktualny rozmiar danych: 11,23 g

Obecna wielkość przechowywania: 12,5 g

Indeksy: 5

Wielkość indeksu: 849,65 m

O niezawodności: To jest bardzo niezawodne. Serwer nie ładuje się, rozmiar indeksu jest w porządku, zapytania są szybkie

O szybkości: Na pewno nie jest tak szybka jak lokalne przechowywanie plików, może 10% wolniejsza, ale wystarczająco szybka, aby można ją było używać w czasie rzeczywistym, nawet gdy obraz wymaga przetworzenia, co w naszym przypadku jest bardzo zależne od php. Skrócono również czas konserwacji i opracowywania: usunięcie jednego lub wielu obrazów stało się tak proste: wystarczy wysłać zapytanie do bazy danych za pomocą prostego polecenia usuwania. Kolejna interesująca rzecz: kiedy zrestartowaliśmy nasz stary serwer z lokalnym magazynem plików (więc milion plików w tysiącach folderów), czasami zawiesza się na godziny, ponieważ system wykonywał kontrolę integralności plików (to naprawdę trwało godziny ...). Nie mamy już tego problemu z gridfs, nasze obrazy są teraz przechowywane w dużych porcjach mongodb (pliki 2GB)

A więc… myślę… Tak, gridfs jest wystarczająco szybki i niezawodny, aby można go było używać do produkcji.

Manu Eidenberger
źródło
9
Jestem zszokowany, że ktoś użyłby raid 0 jako podstawowego magazynu na produkcyjnej witrynie internetowej. Nawet w przypadku dobrych kopii zapasowych zwiększenie prawdopodobieństwa awarii pamięci masowej to dość wysoka cena za lepszą wydajność.
mikerobi
67
Używamy raid 0, ponieważ w naszym konkretnym przypadku dane obrazu mogą być ulotne. Nie ma znaczenia, czy obraz zostanie utracony, ponieważ pobierzemy go ponownie ze strony sprzedawcy. Pragmatycznie moglibyśmy rozważyć, że nasz serwer jest prostym serwerem pamięci podręcznej obrazu.
Manu Eidenberger
Ale aktywnie zwiększasz prawdopodobieństwo awarii (początkowy współczynnik awarii napędu pomnożony przez liczbę wrzecion). Raid 10 byłby idealny, jeśli potrzebujesz więcej zapisów niż odczytów lub Raid 5/6, jeśli potrzebujesz więcej odczytów niż zapisów.
NeuroScr
9
@ManuEidenberger Dlaczego używasz GridFS do przechowywania obrazów, które wolałyby być przechowywane w dokumencie MongoDB? Wydaje mi się, że nie osiągnąłeś limitu rozmiaru dokumentu 16 MB. Przechowywanie obrazu jako BLOB w dokumencie MongoDB byłoby bardziej wydajne, ponieważ nie potrzebujesz warstwy GridFS na wierzchu dokumentów MongoDB.
Arnaud Bouchez
1
Ciekawi mnie też pytanie @ArnaudBouchez. Czy była jakaś korzyść, która sprawiła, że ​​wybrałeś GridFS zamiast zwykłego przechowywania go jako danych binarnych w dokumencie, Manu? Dzięki!
12

Jak wspomniano, może nie być tak szybki jak zwykły system plików, ale daje człowiekowi przewagę nad zwykłymi systemami plików, dla których warto zrezygnować z nieco szybkości.

Ostatecznie, dzięki fragmentowaniu, możesz dojść do punktu, w którym pamięć GridFS stanie się faktycznie szybszą opcją w przeciwieństwie do zwykłego systemu plików i pojedynczego węzła.

Tomek
źródło
6

Uwaga na naprawy większych baz danych - nowy system, który opracowujemy, mongo nie wyszedł gładko, a naprawa 7TB GridFS wygląda na to, że zajmie to 130 godzin.

Z tego powodu myślę, że przyjrzę się przejściu na OpenStack Swift lub Ceph. Jednak do tego czasu było dobrze. A moduł nginx-gridfs jest słodki.

Nacięcie
źródło
Więc jak poszedłeś?
Mukus
5

Moduł nginx-gridfs firmy mdirolf jest świetny i dość łatwy do skonfigurowania. Używamy go w produkcji w paint.ly do obsługi wszystkich obrazów i jak dotąd nie było żadnych problemów.

schallis
źródło
3
Wydaje się, że paint.ly nie jest już dostępny. :(
Marian
2

Nie polecam używania gridfs, chyba że wiesz, co robisz. GridFS to tylko warstwa abstrakcji, która dzieli pliki na porcje i przechowuje je w dwóch kolekcjach. Więcej plików - więcej narzutów. Jeśli oczekujesz, że pliki będą mniej więcej tej samej wielkości, nieprzekraczającej 32 MB - jesteś na dobrej drodze. Nie próbuj przechowywać dużych plików w gridfs. Czemu?

  1. Sterowniki w różnych językach mogą odczytać cały plik (np. Fragmenty) podczas odczytywania małej części pliku.
  2. Modyfikacja pliku może wpłynąć na wszystkie fragmenty i zwiększyć obciążenie bazy danych. Jeśli twój system plików rośnie, będziesz musiał zdecydować o podzieleniu gridfs. Bądź ostrożny! Spójność nie jest gwarantowana podczas inicjalizacji fragmentacji!

Jeśli myślisz o wczytywanym projekcie - rozważ załadowanie plików bezpośrednio do dokumentów (jeśli rozmiar 16M lub mniejszy) lub wybierz inny plik clusterfs i połącz nazwę pliku / i-węzła z logiką.

Mam nadzieję że to pomoże.

Witalij Greck
źródło
4
Jestem całkiem nowy w GridFS, ale z tego, co rozumiem, GridFS to coś więcej niż tylko warstwa abstrakcji, która podwaja liczbę plików. GridFS zapewnia prosty sposób korzystania z funkcji replikacji i fragmentacji bazy danych MongoDB. Wydaje mi się, że inni również wspomnieli, że pliki są przechowywane w fragmentach 2 GB, co, jak wyobrażam, zmniejszyłoby całkowitą liczbę plików, zwłaszcza jeśli ktoś ma bardzo dużą liczbę małych obrazów.
+1 Masz rację. Nawet mniejsze pliki nie przyniosłyby korzyści, gdyby były przechowywane w GridFS. Jeśli twój plik mógłby być przechowywany w dokumencie MongoDB (tj. <Z jego limitu rozmiaru 16 MB), wolałbyś raczej przechowywać plik jako BLOB w dokumencie MongoDB. Omija obciążenie związane z używaniem GridFS na szczycie magazynu MongoDB. Zobacz compose.io/articles/gridfs-and-mongodb-pros-and-cons
Arnaud Bouchez