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.
Czy jest ktoś, kto korzysta z GridFS już w środowisku produkcyjnym lub użyłby go do nowego projektu?
Odpowiedzi:
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.
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.
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.
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?
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.