Comment puis-je stocker et servir le plus efficacement plus d'un million de petits fichiers gzip sur un serveur Web Linux?

J'ai un grand contenu statique que je dois fournir via un serveur Web basé sur Linux. Il s'agit d'un ensemble de plus d'un million de petits fichiers gzip. 90% des fichiers sont inférieurs à 1 Ko et les fichiers restants sont au plus 50 Ko. À l'avenir, cela pourrait atteindre plus de 10 millions de fichiers gzip.

Dois-je mettre ce contenu dans une structure de fichiers ou dois-je envisager de mettre tout ce contenu dans une base de données? S'il se trouve dans une structure de fichiers, puis-je utiliser de grands répertoires ou dois-je envisager des répertoires plus petits?

On m'a dit qu'une structure de fichiers serait plus rapide pour la livraison, mais d'un autre côté, je sais que les fichiers prendront beaucoup d'espace sur le disque, car les blocs de fichiers seront plus de 1K.

Quelle est la meilleure stratégie concernant les performances de livraison?

METTRE À JOUR

Pour mémoire, j'ai effectué un test sous Windows 7, avec un demi-million de fichiers:

Je suppose qu'une structure FS serait plus rapide, mais vous aurez besoin d'une bonne structure de répertoires pour éviter d'avoir des répertoires avec un très grand nombre de fichiers.

Je ne m'inquiéterais pas trop de la perte d'espace disque. Par exemple, avec une taille de bloc de 16 Ko, vous perdrez 15 Go d'espace dans le pire des cas où vous aurez besoin d'un bloc supplémentaire pour chaque fichier. Avec les tailles de disque d'aujourd'hui, ce n'est rien et vous pouvez adapter les paramètres de votre système de fichiers à vos besoins spécifiques.

Si vous choisissez l'option de structure de fichiers, une chose que vous pouvez faire pour améliorer les performances d'E / S disque au moins dans une certaine mesure est de monter la partition avec noatime + nodiratime, sauf si vous en avez besoin. Ils ne sont pas vraiment importants du tout, donc je recommande de le faire. Vous pouvez peut-être également utiliser un disque SSD.

Je pense que la bonne réponse ici dépend de la façon dont les fichiers seront indexés ... ce qui détermine quand un fichier donné est sélectionné pour la livraison.

Si vous effectuez déjà une requête de base de données pour déterminer le nom de votre fichier, vous pouvez très bien trouver que vous feriez mieux de conserver le fichier juste là dans l'enregistrement db, vous pouvez trouver les meilleurs résultats en ajustant certains paramètres de pagination dans votre base de données de choix, puis le stockage des fichiers dans la base de données (ex: des pages plus grandes pour tenir compte de tous les enregistrements de blob), ou vous pouvez trouver que vous êtes encore mieux en utilisant le système de fichiers.

L'option de base de données a un peu plus de chances de fonctionner car, avec un million d'enregistrements, il est probable que chaque fichier ne sera pas également interrogé. Si vous êtes dans une situation où un fichier peut être interrogé plusieurs fois de suite, ou presque de suite, la base de données peut agir comme un cache de facto pour les fichiers récemment récupérés, auquel cas vous aurez souvent le résultat de votre fichier déjà chargé en mémoire. Vous devrez peut-être régler soigneusement les éléments internes de votre moteur de base de données pour obtenir le comportement souhaité.

Mais la principale chose à retenir de ma réponse est que vous ne savez pas vraiment ce qui fonctionnera le mieux avant de l'essayer avec des données de test représentatives et de mesurer les résultats.

Avec les systèmes de fichiers modernes, cela ne devrait pas poser beaucoup de problème. J'ai testé XFS avec 1 milliard de fichiers dans le même répertoire, et je suis à peu près sûr que ext4 fonctionnera bien aussi (tant que le système de fichiers lui-même n'est pas trop gros). Avoir suffisamment de mémoire pour mettre en cache les entrées du répertoire; une mémoire cache de processeur plus importante aidera également beaucoup.