Probablemente participe en un proyecto en el que un componente importante es el almacenamiento de una gran cantidad de archivos (en este caso imágenes, pero solo debe funcionar como almacenamiento de archivos).Almacenamiento de imágenes a gran escala
Se espera que la cantidad de archivos entrantes sea de alrededor de 500,000 por semana (con un promedio de alrededor de 100 Kb cada uno), alcanzando un máximo de 100,000 archivos por día y 5 por segundo. Se espera que el número total de archivos llegue a decenas de millones antes de alcanzar un equilibrio en el que los archivos expiran por varias razones a la velocidad de entrada.
Necesito un sistema que pueda almacenar alrededor de 5 archivos por segundo en horas pico, mientras lee alrededor de 4 y elimina 4 en cualquier momento.
Mi idea inicial es que un sistema de archivos NTFS simple con un servicio simple para almacenar, caducar y leer en realidad debería ser suficiente. Me imagino que el servicio creará subcarpetas para cada año, mes, día y hora para mantener el número de archivos por carpeta al mínimo y para permitir la caducidad manual en caso de que sea necesario.
Se ha discutido una gran solución NTFS here, pero aún podría seguir algunos consejos sobre qué problemas esperar al construir un almacenamiento con las especificaciones mencionadas, qué problemas de mantenimiento esperar y qué alternativas existen. Preferentemente, me gustaría evitar un almacenamiento distribuido, si es posible y práctico.
edición
Gracias por todos los comentarios y sugerencias. Algunos más información de bonificación sobre el proyecto:
Esta no es una aplicación web donde las imágenes son suministradas por los usuarios finales. Sin revelar demasiado, ya que está en la fase de contrato, está más en la categoría de control de calidad. Piensa en la planta de producción con cinta transportadora y sensores. No es un control de calidad tradicional, ya que el valor del producto depende completamente de que la base de datos de imágenes y metadatos funcione sin problemas.
Las imágenes son accedidas en un 99% por una aplicación autónoma en orden primero en entrar, primero en salir, pero también se producirá el acceso aleatorio de una aplicación de usuario. Las imágenes anteriores a un día servirán principalmente para fines de archivo, aunque ese propósito también es muy importante.
La caducidad de las imágenes sigue reglas complejas por varias razones, pero en algún momento se deben eliminar todas las imágenes. Las reglas de eliminación siguen la lógica empresarial en función de los metadatos y las interacciones del usuario.
Habrá tiempo de inactividad cada día, donde se puede realizar el mantenimiento.
Preferiblemente, el almacenamiento de archivos no tendrá que volver a comunicar la ubicación de la imagen al servidor de metadatos. La ubicación de la imagen debe deducirse de manera única de los metadatos, posiblemente a través de una base de datos de mapas, si se elige algún tipo de sistema hash o distribuido.
Así que mis preguntas son:
- Qué tecnologías va a hacer un trabajo robusto?
- ¿Qué tecnologías tendrán los costos de implementación más bajos?
- ¿Qué tecnologías será más fácil de mantener por el departamento de TI del cliente?
- ¿Qué riesgos existen para una tecnología dada a esta escala (5-20 TB de datos, 10-100 millones de archivos)?
Tenga en cuenta los límites de directorio de archivos de #, nos encontramos con un problema en Redhat con un límite máximo de archivos por dir, fyi. – Jakub
Es por eso que quería dividir los archivos en carpetas según su año, mes, día y hora. Después de todo, no espero más de 18000 archivos por hora. – Holstebroe
También vea http://stackoverflow.com/questions/2104720/memory-leak-using-sql-filestream/2104944#2104944 –