{"id":55408,"date":"2020-01-20T00:00:00","date_gmt":"2020-01-19T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/effektivnoe-hranenie-soten-millionov-malenkih-fajlov-self-hosted-reshenie"},"modified":"2020-02-18T14:03:31","modified_gmt":"2020-02-18T11:03:31","slug":"effektivnoe-hranenie-soten-millionov-malenkih-fajlov-self-hosted-reshenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/effektivnoe-hranenie-soten-millionov-malenkih-fajlov-self-hosted-reshenie","title":{"rendered":"Stockage efficace de centaines de millions de petits fichiers. Solution auto-h\u00e9berg\u00e9e","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Stockage
\n
\nCh\u00e8re communaut\u00e9, cet article sera consacr\u00e9 \u00e0 la gestion efficace de centaines de millions de petits fichiers. \u00c0 ce stade, une solution finale est propos\u00e9e pour les syst\u00e8mes de fichiers compatibles POSIX, avec un soutien complet pour les verrous, y compris les verrous clusteris\u00e9s, et apparemment m\u00eame sans b\u00e9quilles cette fois-ci.<\/p>\n

C'est pourquoi j'ai \u00e9crit mon propre serveur sp\u00e9cialis\u00e9 pour cet objectif.
\nAu cours de la mise en \u0153uvre de cette t\u00e2che, nous avons pu r\u00e9soudre le probl\u00e8me principal et \u00e9conomiser de l'espace disque et de la m\u00e9moire vive, que notre syst\u00e8me de fichiers en cluster consommait sans rel\u00e2che. En effet, une telle quantit\u00e9 de fichiers est nuisible pour n'importe quel syst\u00e8me de fichiers en cluster. <\/a><\/noindex><\/p>\n

L'id\u00e9e est simple :<\/p>\n

En termes simples, les petits fichiers sont t\u00e9l\u00e9charg\u00e9s via le serveur, ils sont enregistr\u00e9s directement dans une archive, puis \u00e9galement lus \u00e0 partir de celle-ci, tandis que les gros fichiers sont stock\u00e9s s\u00e9par\u00e9ment. Sch\u00e9ma : 1 dossier = 1 archive, ce qui nous donne plusieurs millions d'archives contenant de petits fichiers, et non pas plusieurs centaines de millions de fichiers. Et tout cela est r\u00e9alis\u00e9 pleinement, sans aucun script ni dispersion de fichiers dans des archives tar\/zip.<\/p>\n

Je vais essayer de r\u00e9sumer, je m'excuse d'avance si le post s'av\u00e8re dense.<\/p>\n

Tout a commenc\u00e9 lorsque je n'ai pas pu trouver de serveur ad\u00e9quat capable de stocker des donn\u00e9es re\u00e7ues via le protocole HTTP directement dans des archives, afin qu'il n'y ait pas d'inconv\u00e9nients typiques des archives ordinaires et des stockages d'objets. La raison de cette recherche \u00e9tait un cluster Origin en pleine expansion de 10 serveurs, qui avait accumul\u00e9 250 000 000 petits fichiers, et la tendance \u00e0 la hausse ne semblait pas vouloir s'arr\u00eater.<\/p>\n

Pour ceux qui n'aiment pas lire les articles, voici une documentation simplifi\u00e9e :<\/b><\/p>\n

ici<\/a><\/noindex> et ici<\/a><\/noindex>.<\/p>\n

Et docker au passage, actuellement il n'y a d'option qu'avec nginx \u00e0 l'int\u00e9rieur \u00e0 tout hasard :<\/p>\n

docker run -d --restart=always -e host=localhost -e root=\\\/var\\\/storage \n-v \\\/var\\\/storage:\\\/var\\\/storage --name wzd -p 80:80 eltaline\\\/wzd<\/code><\/pre>\n
\nSuivant :<\/p>\n
Lorsque le nombre de fichiers est tr\u00e8s \u00e9lev\u00e9, des ressources consid\u00e9rables sont n\u00e9cessaires, et, ce qui est le plus frustrant, une partie de celles-ci est gaspill\u00e9es. Par exemple, lors de l'utilisation d'un syst\u00e8me de fichiers en cluster (dans ce cas, MooseFS), un fichier, quelle que soit sa taille r\u00e9elle, occupe toujours au minimum 64 Ko. Donc, pour des fichiers de 3, 10 ou 30 Ko, 64 Ko sont n\u00e9cessaires sur le disque. Avec un quart de milliard de fichiers, nous perdons de 2 \u00e0 10 t\u00e9raoctets. Il est impossible de continuer \u00e0 cr\u00e9er de nouveaux fichiers ind\u00e9finiment, car dans MooseFS, il y a une limitation : pas plus d'un milliard avec une r\u00e9plique de chaque fichier.<\/p>\n
\u00c0 mesure que le nombre de fichiers augmente, il faut beaucoup de m\u00e9moire vive pour les m\u00e9tadonn\u00e9es. De plus, des copies de m\u00e9tadonn\u00e9es fr\u00e9quentes et volumineuses contribuent \u00e0 l'usure des disques SSD.<\/p>\n
Serveur wZD. Nous mettons de l'ordre sur les disques.<\/b><\/p>\n
Le serveur est \u00e9crit en Go. Tout d'abord, j'avais besoin de r\u00e9duire le nombre de fichiers. Comment faire cela ? Gr\u00e2ce \u00e0 l'archivage, mais dans ce cas, sans compression, car mes fichiers sont des images compress\u00e9es. BoltDB m'a aid\u00e9, bien que j'aie d\u00fb corriger certains d\u00e9fauts, ce qui est mentionn\u00e9 dans la documentation.<\/p>\n
Au total, au lieu d'un quart de milliard de fichiers, il ne reste que 10 millions d'archives Bolt dans mon cas. Si j'avais eu la possibilit\u00e9 de modifier la structure actuelle de remplissage des r\u00e9pertoires, il serait peut-\u00eatre possible de r\u00e9duire cela \u00e0 environ 1 million de fichiers. <\/p>\n
Tous les petits fichiers sont empaquet\u00e9s dans des archives Bolt, qui obtiennent automatiquement les noms des r\u00e9pertoires dans lesquels ils se trouvent, tandis que tous les gros fichiers restent \u00e0 c\u00f4t\u00e9 des archives, car il n'est pas judicieux de les emballer. C'est configurable. Les petits fichiers sont archiv\u00e9s, les gros restent inchang\u00e9s. Le serveur fonctionne de mani\u00e8re transparente avec les deux types.<\/p>\n
Architecture et caract\u00e9ristiques du serveur wZD.<\/b><\/p>\n
\"Stockage
\n
\nLe serveur fonctionne sous les syst\u00e8mes d'exploitation Linux, BSD, Solaris et OSX. J'ai test\u00e9 uniquement pour l'architecture AMD64 sous Linux, mais il devrait \u00e9galement convenir pour ARM64, PPC64, MIPS64.<\/p>\n
Les principales fonctionnalit\u00e9s :<\/b><\/p>\n