Acceso/almacenamiento de archivos más rápido?

Question

Tengo alrededor de 750,000,000 de archivos que necesito almacenar en el disco. Además, necesito poder acceder a estos archivos aleatoriamente (cualquier archivo dado en cualquier momento) en el , el menor tiempo posible. ¿Qué debo hacer para que el acceso a estos archivos sea más rápido?

Piense en ello como una tabla hash, solo las claves hash son los nombres de los archivos y los valores asociados son los datos de los archivos.

Un compañero de trabajo dice que los organice en directorios como este: si quiero almacenar un archivo llamado "foobar.txt" y está almacenado en el disco D :, coloque el archivo en "D: \ f \ o \ o \ b \ a \ r. \ t \ x \ t ". No pudo explicar por qué fue una buena idea. ¿Hay algo en esta idea?

¿Alguna idea?

El meollo de esto es la búsqueda de un archivo. ¿Cuál es la forma más rápida de encontrar un archivo por el nombre para abrir?

EDIT:

tengo ningún control sobre el sistema de archivos en los que se almacena estos datos. Va a ser NTFS o FAT32.

Almacenar los datos del archivo en una base de datos no es una opción.

Los archivos van a ser muy pequeños, con un máximo de probablemente 1 kb.

Las unidades van a ser de estado sólido.

El acceso a los datos es prácticamente aleatorio, pero probablemente podría encontrar una prioridad para cada archivo según la frecuencia con que se solicite. Se accederá a algunos archivos mucho más que otros.

Los elementos se agregarán constantemente, y algunas veces se eliminarán.

No sería práctico consolidar varios archivos en archivos individuales porque no hay una asociación lógica entre los archivos.

Me encantaría recopilar algunas métricas mediante la realización de pruebas sobre estas cosas, pero ese esfuerzo podría ser tan agotador como el proyecto mismo.

Edit2:

Quiero upvote varias respuestas exhaustivas, ya sea que estén en el clavo o no, y no puede debido a mi condición de novato. ¡Lo siento chicos!

Answer 1

¿Existe alguna relación entre los archivos individuales? En cuanto a los tiempos de acceso, las carpetas en las que colocas cosas no afectarán mucho; las ubicaciones físicas en el disco son lo que importa.

Answer 2

Parece que esto va a ser en gran parte una cuestión de elección del sistema de archivos. Una opción para mirar podría ser ZFS, está diseñada para aplicaciones de gran volumen.

Quizás también desee considerar el uso de una base de datos relacional para este tipo de cosas. 750 millones de filas son una base de datos de tamaño mediano, por lo que cualquier DBMS robusto (por ejemplo, PostgreSQL) podría manejarlo bien. También puede almacenar blobs arbitrarios en la base de datos, por lo que sea lo que sea que vaya a almacenar en los archivos del disco, puede guardarlos en la base de datos.

Actualización: Su información adicional es sin duda útil. Dada una opción entre FAT32 y NTFS, entonces definitivamente elige NTFS. No almacene demasiados archivos en un único directorio, 100.000 podría ser un límite superior a tener en cuenta (aunque tendrá que experimentar, no hay una regla rígida). La sugerencia de su amigo de un nuevo directorio para cada letra es probablemente demasiado, podría considerar dividirla en cuatro letras o algo así. El mejor valor para elegir depende de la forma de su conjunto de datos.

El motivo por el que se rompe el nombre es una buena idea es que normalmente el rendimiento de los sistemas de archivos disminuye a medida que aumenta el número de archivos en un directorio. Esto depende en gran medida del sistema de archivos en uso, por ejemplo FAT32 será horrible con probablemente solo unos pocos miles de archivos por directorio. Usted no desea romper los nombres de archivo demasiado mucho, por lo que no sólo puede disminuir el número de búsquedas en los directorios del sistema de archivos tendrá que hacer.

Answer 3

Por qué no es el almacenamiento de los caminos en una tabla de base aceptable?

Answer 4

Supongo que está pensando en una estructura de datos Trie para crear en el disco donde el nodo es un directorio.

Answer 5

Esto depende de muchos factores: altamente

• Qué sistema de archivos está utilizando?
• ¿Qué tan grande es cada archivo?
• ¿Qué tipo de unidades está usando?
• ¿Cuáles son los patrones de acceso?

acceso a los archivos puramente al azar es muy caro en los discos tradicionales. Una mejora significativa que puede obtener es usar un disco de estado sólido.

Si puede razonar un patrón de acceso, es posible que pueda aprovechar la localidad de referencia para colocar estos archivos.

Otra forma posible es utilizar un sistema de base de datos y almacenar estos archivos en la base de datos para aprovechar el mecanismo de almacenamiento en caché del sistema.

Actualización:

Dada su actualización, es que possbile a consolidar algunos archivos? Los archivos 1k no son muy eficientes para almacenar ya que los sistemas de archivos (fat32, ntfs) tienen un tamaño de clúster y cada archivo usará el tamaño del clúster de todos modos, incluso si es más pequeño que el tamaño del clúster. Por lo general, hay un límite en la cantidad de archivos en cada carpeta, con problemas de rendimiento. Puede hacer un punto de referencia simple colocando hasta 10k archivos en una carpeta para ver cuánto se degrada el rendimiento.

Si está configurado para usar la estructura trie, sugeriría encuestar la distribución de nombres de archivos y luego dividirlos en diferentes carpetas basadas en la distribución.

Answer 6

Revisaría el modelo hadoops.

P

Answer 7

Esto depende en gran medida de lo que el sistema de archivos que se va a almacenar los archivos en. Las capacidades de los sistemas de archivos para manejar una gran cantidad de archivos varían ampliamente.

su compañero de trabajo está sugiriendo esencialmente el uso de un Trie data structure. El uso de dicha estructura de directorio significa que en cada nivel de directorio hay solo un puñado de archivos/directorios para elegir; Esto podría ayudar porque a medida que el número de archivos en un directorio aumenta el tiempo de acceso a uno de ellos también (la diferencia de tiempo real depende del tipo de sistema de archivos).

Dicho esto, yo personalmente no iría tantos niveles profundos: de tres a cuatro niveles deberían ser suficientes para brindar los beneficios de rendimiento; la mayoría de los niveles posteriores probablemente tendrán entradas (suponiendo que los nombres de los archivos no siguen ningún patrón en particular).

Además, lo haría almacene el archivo en sí mismo con su nombre completo, esto hará que sea más fácil atravesar esta estructura de directorio también manualmente, si es necesario.

lo tanto, me gustaría almacenar foobar.txt como f/o/o/b/foobar.txt

Answer 8

En primer lugar, el tamaño del archivo es muy pequeño. Cualquier sistema de archivos comerá algo como al menos 4 veces más espacio. Quiero decir que cualquier archivo en el disco ocupará 4kb para un archivo de 1kb. Especialmente en discos SSD, el sector de 4kb será la norma.

Así que hay que agrupar varios archivos en 1 archivo físico. 1024 archivo en 1 archivo de almacenamiento parece razonable. Para ubicar los archivos individuales en estos archivos de almacenamiento, debe usar algunos RDBMS (se mencionó PostgreSQL y es bueno, pero SQLite puede ser más adecuado para esto) o una estructura similar para hacer el mapeo.

La estructura de directorios sugerida por su amigo suena bien pero no resuelve el problema de almacenamiento físico. Puede usar una estructura de directorios similar para almacenar los archivos de almacenamiento. Es mejor nombrarlos usando un sistema numérico.

Si es posible, no les permiten realizar un formateo en FAT32, NTFS o al menos algunos de sistema de archivos recientes de sabor de Unix. A medida que el tamaño total de los archivos no es tan grande, NTFS puede ser suficiente, pero ZFS es la mejor opción ...

Answer 9

que el algoritmo de archivos va a funcionar, pero no es óptima. Creo que usar "segmentos" de 2 o 3 caracteres sería mejor para el rendimiento, especialmente cuando empiezas a considerar hacer copias de seguridad.

Por ejemplo:
d: \ almacenamiento \ fo \ ob \ ar \ foobar.txt
o
d: \ almacenamiento \ foo \ bar foobar.txt \

Hay algunas ventajas a usar este tipo de algoritmo:

1. No es necesario acceder a la base de datos.
2. Los archivos se extendió a cabo a través de muchos directorios. Si no los distribuye, tendrá graves problemas de rendimiento. (Recuerdo vagamente haber escuchado sobre alguien con problemas en ~ 40,000 archivos en una sola carpeta, pero no estoy seguro de ese número.)
3. No es necesario buscar un archivo. Puede averiguar exactamente dónde estará un archivo desde el nombre del archivo.
4. simplicidad. Puede transferir fácilmente este algoritmo a casi cualquier idioma.

Hay algunos abajo lados a esto también:

1. Muchos directorios pueden conducir a disminuir las copias de seguridad. Imagina hacer diffs recursivos en estos directorios.
2. Escalabilidad. ¿Qué sucede cuando se queda sin espacio en disco y necesita agregar más almacenamiento?
3. Los nombres de sus archivos no pueden contener espacios.

Answer 10

Sé que esto es un par de años de retraso, pero tal vez esto puede ayudar al individuo siguiente ..

Mi sugerencia utilizar una SAN, asignado a una unidad Z que otros servidores pueden asignar a también. No me gustaría ir con la ruta de la carpeta a la que su amigo dijo ir, pero más con una unidad: \ clientid \ year \ month \ day \ y si ingiere más de 100k documentos al día, entonces puede agregar subcarpetas por hora e incluso minutos si es necesario. De esta forma, nunca tendrá más de 60 subcarpetas mientras baja hasta segundos si es necesario. Almacene los enlaces en SQL para una recuperación e informes rápidos. Esto hace que la ruta de la carpeta sea bastante corta, por ejemplo: Z: \ 05 \ 2004 \ 02 \ 26 \ 09 \ 55 \ filename.txt, por lo que no se encontrará con ninguna limitación de 256 en general.

Espero que ayude a alguien. :)