Tenemos cientos de miles de imágenes jpg en una estructura de carpetas de Windows como esta, pero es realmente difícil interactuar y trabajar con ellas de manera ágil (listar lleva tiempo, copiar lleva tiempo, etc.). Aquí está la estructura:
images/
1/
10001/
10001-a.jpg
10001-b.jpg
...
10001-j.jpg (10 images in each XXXXX folder)
10002/
10003/
...
19999/
2/
20001/
20002/
20003/
...
29999/
3/
4/
5/
6/
7/
8/
9/
Ahora, explorar estas imágenes es un poco lento porque hay aprox. 10 000 carpetas en cada carpeta X y enumerarlas simplemente lleva tiempo.
¿Existe una mejor manera de organizar las imágenes con menos subcarpetas/elementos? ¿Cambiar la estructura a esto tendría algún efecto?
images/
1/
0/
0/
0/
0/
1/
2/
3/
4/
5/
6/
7/
8/
9/
10000/ (image folder, same as path)
10000-a.jpg
10000-b.jpg
...
10000-j.jpg (10 images in each image folder)
1/
2/
3/
4/
5/
6/
7/
8/
9/
1/
2/
3/
4/
5/
6/
7/
8/
9/
1/
2/
3/
4/
5/
6/
7/
8/
9/
2/
3/
4/
5/
6/
7/
8/
9/
Por lo tanto, localizar la imagen 48617-c.jpg equivaldría a la ruta 4/8/6/1/7/48617/48617-c.jpg.
La razón para tener una carpeta separada con el número de ruta completo 48617 es simplificar la copia de un lote completo de 10 imágenes (copiando la carpeta completa).
Ahora... ninguna carpeta tendrá más de 11 subcarpetas inmediatas, pero habrá muchas carpetas adicionales de un solo dígito para fines de separación. ¿Esta configuración aceleraría la navegación y la interacción si varios usuarios agregan/copian/eliminan/etc. imágenes?
Respuesta1
Windows es un poco especial cuando se trata del diseño de carpetas con millones de archivos. Especialmente las imágenes, ya que el Explorador de Windows las trata de manera especial. Dicho esto, hay algunas pautas a seguir para evitar que las cosas se pongan mal.tambiénfuera de alcance:
- Si tiene la intención de explorar la estructura de directorios desde el Explorador de Windows por cualquier motivo, manténgala por debajo de 10,000 entradas en un directorio (archivos y subdirectorios).
- Si va a interactuar con él únicamente desde las utilidades cli o el código, el límite de 10K es mucho más flexible.
- No cree DEMASIADOS subdirectorios, cada directorio que cree es otra operación discreta que debe realizar una copia al copiar.
- Si cada archivo crea N directorios, el número deobjetos del sistema de archivoscreado por ese archivo será 1+N, lo que escala linealmente sus tiempos de copia.
- Un árbol corto y exponencial (es decir, tres niveles de directorios, cada uno con 256 subdirectorios) puede escalar sorprendentemente mucho antes de alcanzar el límite de 10K por directorio.
- Si accede a él con código, opte por aperturas directas en lugar de analizar las listas de directorios antes de abrir. Un fopen() fallido seguido de un escaneo de directorio es más rápido que un escaneo de directorio seguido de un fopen() garantizado en muchos casos.
Advertencias:
- El recuento de archivos es inmutable, pero el recuento de directorios depende de usted. La SUMA de esos dos recuentos afecta la rapidez con la que se realizan las operaciones de copia.
- Intente, si es posible, no navegar con el Explorador de Windows a menos que sea necesario. No funciona bien con directorios grandes y no hay mucho que puedas hacer al respecto.
Respuesta2
Hay mucha buena información sobre matemáticas en mi respuesta de¿Cómo influye la complejidad del directorio en los i-nodos?
Dicho esto, diferentes sistemas de archivos manejan grandes cantidades de archivos en directorios de diversas maneras. Algunos están bien con 10.000 entradas, otros ceden. Como regla general inventada rápidamente, 1000 es probablemente un buen límite objetivo si tienes control del diseño. Las entradas en un directorio generalmente se almacenan como una especie de lista y depende de la aplicación de lectura ordenarlas. Por ejemplo, lsen el mundo Unix lee cosas en la memoria según el orden del directorio y luego las imprime en orden alfabético.
Eche un vistazo a las matemáticas de la otra pregunta. Considere también lo que dijo sysadmin1338 acerca de que Explorer se comporta de manera diferente. Explorer creará miniaturas de cualquier cosa que reconozca como imagen y luego las leerá para mostrarlas. Eso es mucho IO de disco para mirar un directorio que está repleto de archivos.
Respuesta3
Dependiendo de si tiene los recursos para desarrollar un sistema de este tipo, éste parece un buen candidato para una base de datos de SQL Server que utiliceCORRIENTE DE ARCHIVOSalmacenamiento para los archivos. De esa manera, deja la organización de los directorios a SQL Server y lo único de lo que tiene que preocuparse es de cómo administrar los datos. Probablemente podría utilizar SQL Express ya que los datos de FILESTREAM no se tienen en cuenta al calcular el tamaño de la base de datos.