Jak najskuteczniej przechowywać i obsługiwać ponad 1 000 000 małych spakowanych plików na serwerze sieciowym z systemem Linux?

Mam dużą statyczną treść, którą muszę dostarczyć za pośrednictwem serwera WWW opartego na systemie Linux. Jest to zestaw ponad miliona małych plików gzip. 90% plików ma mniej niż 1 KB, a pozostałe pliki mają najwyżej 50 KB. W przyszłości może to wzrosnąć do ponad 10 milionów plików gzip.

Czy powinienem umieścić tę zawartość w strukturze plików, czy powinienem rozważyć umieszczenie całej tej zawartości w bazie danych? Jeśli jest w strukturze plików, czy mogę używać dużych katalogów, czy powinienem rozważyć mniejsze katalogi?

Powiedziano mi, że struktura plików będzie szybsza do dostarczenia, ale z drugiej strony wiem, że pliki zajmą dużo miejsca na dysku, ponieważ bloki plików będą większe niż 1 KB.

Jaka jest najlepsza strategia dotycząca wydajności dostawy?

AKTUALIZACJA

Dla przypomnienia przeprowadziłem test w systemie Windows 7 z pół milionem plików:

Domyślam się, że struktura FS byłaby szybsza, ale będziesz potrzebować dobrej struktury katalogów, aby uniknąć katalogów z bardzo dużą liczbą plików.

Nie martwiłbym się zbytnio o utracone miejsce na dysku. Na przykład przy rozmiarze bloku 16 KB stracisz 15 GB miejsca w najgorszym przypadku, gdy potrzebujesz jednego dodatkowego bloku na każdy plik. Przy dzisiejszych rozmiarach dysków to nic i możesz dostosować parametry swojego systemu plików do swoich potrzeb.

Jeśli wybierzesz opcję struktury plików, jedną z rzeczy, które możesz zrobić, aby poprawić wydajność We / Wy dysku przynajmniej w pewnym stopniu, jest zamontowanie partycji za pomocą noatime + nodiratime, chyba że musisz je mieć. Nie są tak naprawdę ważne, więc polecam to zrobić. Może możesz także użyć dysku SSD.

Myślę, że poprawna odpowiedź tutaj zależy od tego, w jaki sposób pliki będą indeksowane ... co decyduje o tym, kiedy dany plik zostanie wybrany do dostarczenia.

Jeśli już tworzysz zapytanie do bazy danych w celu ustalenia nazwy pliku, możesz z dużym prawdopodobieństwem stwierdzić, że lepiej jest przechowywać plik bezpośrednio w rekordzie db, możesz znaleźć najlepsze wyniki po poprawieniu niektórych ustawień stronicowania w bazie danych wybór, a następnie przechowywanie plików w bazie danych (np. większe strony, aby uwzględnić wszystkie rekordy obiektów blob), lub może się okazać, że lepiej będzie, korzystając z systemu plików.

Opcja bazy danych ma nieco większą szansę na wypracowanie, ponieważ przy milionie rekordów jest prawdopodobne, że nie będzie tak samo prawdopodobne, że każdy plik zostanie zapytany. Jeśli znajdujesz się w sytuacji, w której jeden plik może być przeszukiwany kilka razy z rzędu lub prawie z rzędu, baza danych może działać jako faktyczna pamięć podręczna dla ostatnio pobranych plików, w którym to przypadku często otrzymasz wynik pliku już załadowany do pamięci. Konieczne może być staranne dostrojenie elementów wewnętrznych silnika bazy danych, aby uzyskać pożądane zachowanie.

Ale najważniejsze, aby oderwać się od mojej odpowiedzi, jest to, że tak naprawdę nie wiesz, co będzie najlepsze, dopóki nie wypróbujesz tego z reprezentatywnymi danymi testowymi i nie zmierzysz wyników.

W nowoczesnych systemach plików nie powinno stanowić większego problemu. Przetestowałem XFS z 1 miliardem plików w tym samym katalogu i jestem prawie pewien, że ext4 też sobie poradzi (o ile sam system plików nie jest zbyt duży). Posiadaj wystarczającą ilość pamięci, aby buforować wpisy katalogu; większa pamięć podręczna procesora również bardzo pomoże.