{"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\/es\/blog\/administrirovanie\/effektivnoe-hranenie-soten-millionov-malenkih-fajlov-self-hosted-reshenie","title":{"rendered":"Almacenamiento eficiente de cientos de millones de peque\u00f1os archivos. Soluci\u00f3n autogestionada","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Almacenamiento
\n
\nEstimado comunidad, este art\u00edculo estar\u00e1 dedicado al almacenamiento y recuperaci\u00f3n eficientes de cientos de millones de peque\u00f1os archivos. En esta etapa, se presenta una soluci\u00f3n final para sistemas de archivos compatibles con POSIX con soporte completo para bloqueos, incluidos los de cl\u00faster, y parece que incluso sin parches.<\/p>\n

Por lo tanto, para este prop\u00f3sito, escrib\u00ed mi propio servidor especializado.
\nA medida que implementaba esta tarea, pude resolver el problema principal y, al mismo tiempo, lograr un ahorro en el espacio en disco y la memoria RAM que consum\u00eda nuestra sistem\u00e1tica de archivos en cl\u00faster. Tal cantidad de archivos es perjudicial para cualquier sistema de archivos de cl\u00faster. <\/a><\/noindex><\/p>\n

La idea es la siguiente:<\/p>\n

En t\u00e9rminos simples, a trav\u00e9s del servidor se cargan archivos peque\u00f1os, que se almacenan directamente en un archivo de archivero, y as\u00ed tambi\u00e9n se leen desde \u00e9l, mientras que los archivos grandes se colocan al lado. Esquema: 1 carpeta = 1 archivo de archivero, lo que resulta en varios millones de archivos de archivero con peque\u00f1os archivos, en lugar de varios cientos de millones de archivos. Y todo esto est\u00e1 completamente implementado, sin ning\u00fan script y distribuciones de archivos en archivos tar\/zip.<\/p>\n

Tratar\u00e9 de exponerlo m\u00e1s brevemente, pido disculpas de antemano si la publicaci\u00f3n es extensa.<\/p>\n

Todo comenz\u00f3 porque no pude encontrar un servidor adecuado en el mundo que pudiera almacenar datos recibidos a trav\u00e9s del protocolo HTTP directamente en archivos de archivero, de manera que no hubiera las desventajas inherentes a los archivos de archivero comunes y a los almacenes de objetos. La raz\u00f3n de la b\u00fasqueda fue el cl\u00faster de Origin, que se hab\u00eda expandido a gran escala con 10 servidores, y que ya acumulaba 250,000,000 archivos peque\u00f1os, mientras que la tendencia de crecimiento no mostraba signos de detenerse.<\/p>\n

Para aquellos que no les gusta leer art\u00edculos y prefieren una documentaci\u00f3n m\u00e1s simple:<\/b><\/p>\n

: uno de los indicadores m\u00e1s importantes sobre DEX).<\/a><\/noindex> y : uno de los indicadores m\u00e1s importantes sobre DEX).<\/a><\/noindex>.<\/p>\n

Y docker tambi\u00e9n, ahora hay una opci\u00f3n solo junto con nginx por si acaso:<\/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
\nSiguiente:<\/p>\n
Si hay muchos archivos, se requieren recursos significativos, y lo m\u00e1s lamentable es que parte de ellos se desperdicia. Por ejemplo, al utilizar un sistema de archivos en cl\u00faster (en este caso, MooseFS), un archivo, independientemente de su tama\u00f1o real, siempre ocupa un m\u00ednimo de 64 KB. Es decir, para archivos de 3, 10 o 30 KB se requieren 64 KB en el disco. Si hay un cuarto de mil millones de archivos, perdemos entre 2 y 10 terabytes. No ser\u00e1 posible crear nuevos archivos indefinidamente, ya que en MooseFS hay una limitaci\u00f3n: no m\u00e1s de 1 mil millones con una r\u00e9plica de cada archivo.<\/p>\n
A medida que aumenta la cantidad de archivos, se necesita mucha memoria RAM para los metadatos. Adem\u00e1s, los frecuentes grandes vol\u00famenes de metadatos contribuyen al desgaste de las unidades SSD.<\/p>\n
Servidor wZD. Organizando los discos.<\/b><\/p>\n
El servidor est\u00e1 escrito en Go. Primero necesitaba reducir la cantidad de archivos. \u00bfC\u00f3mo hacerlo? A trav\u00e9s de la archivaci\u00f3n, pero en este caso sin compresi\u00f3n, ya que mis archivos son im\u00e1genes comprimidas. BoltDB fue de gran ayuda, aunque hubo que eliminarle algunos inconvenientes, lo que est\u00e1 reflejado en la documentaci\u00f3n.<\/p>\n
En total, en lugar de un cuarto de mil millones de archivos, en mi caso solo quedaron 10 millones de archivos Bolt. Si hubiera tenido la posibilidad de cambiar la estructura actual de llenado de las carpetas, posiblemente se podr\u00eda haber reducido a aproximadamente 1 mill\u00f3n de archivos. <\/p>\n
Todos los archivos peque\u00f1os se empaquetan en archivos Bolt, que autom\u00e1ticamente reciben los nombres de las carpetas en las que se encuentran, mientras que todos los archivos grandes permanecen al lado de los archivos comprimidos, no tiene sentido empaquetarlos, esto es configurable. Los peque\u00f1os, se archivan, los grandes, se dejan sin cambios. El servidor funciona de manera transparente con ambos.<\/p>\n
Arquitectura y caracter\u00edsticas del servidor wZD.<\/b><\/p>\n
\"Almacenamiento
\n
\nEl servidor funciona bajo sistemas operativos Linux, BSD, Solaris y OSX. Solo lo he probado para la arquitectura AMD64 bajo Linux, pero deber\u00eda ser adecuado tambi\u00e9n para ARM64, PPC64, MIPS64.<\/p>\n
Principales caracter\u00edsticas:<\/b><\/p>\n