Consideraciones ¿Dónde almacenar documentos, en el servidor de archivos o en DB?

Question

Tengo que tomar una decisión de diseño con respecto a los documentos cargados en mi sitio web: puedo almacenarlos en mi servidor de archivos en algún lugar o puedo almacenarlos como un blob en mi base de datos (MSSQL 2005). Si hace alguna diferencia en la decisión de diseño, estos documentos son confidenciales y deben tener un cierto grado de protección.

Las consideraciones en las que he pensado son:

1. El almacenamiento en el servidor de archivos hace que los números de archivos huuuuuuuuuuge se descarguen en un solo directorio y, por lo tanto, hay un acceso más lento, a menos que pueda resolver una definición semántica razonable para una estructura de árbol de directorio
2. OTOH, supongo que el servidor de archivos puede manejar la compresión algo mejor que el DB ... ¿o me equivoco?
3. Mis instintos me dicen que la seguridad del DB es más fuerte que la del servidor de archivos, pero no estoy seguro de si eso es necesariamente cierto.
4. No sé cómo tener terabytes de blobs en mi DB afectará el rendimiento.

Agradecería mucho algunas recomendaciones aquí. ¡Gracias!

Answer 1

En SQL Server 2005, solo tiene la opción de usar VARBINARY(MAX) Para almacenar los archivos dentro de la tabla de la base de datos, o luego mantenerlos afuera.

El inconveniente obvio de dejarlos fuera de la base de datos es que la base de datos realmente no puede controlar lo que les sucede; Podrían ser trasladados, renombrados, eliminados .....

servidor SQL 2008 presenta el FILESTERAM atribuir VARBINARY(MAX) tipos, que le permiten dejar los archivos fuera de la tabla de la base de datos, pero aún así bajo el control transaccional de la base de datos, por ejemplo, no puede simplemente eliminar los archivos del disco, los archivos son parte integral de la base de datos y, por lo tanto, se copian y se copian con eso. ¡Genial si lo necesitas, pero podría hacer algunas copias de seguridad enormes! :-)

El lanzamiento de SQL Server 2008 presentó algunas "mejores prácticas" en cuanto a cuándo almacenar cosas en la base de datos directamente y cuándo usar FileStream. Estos son:

• Si los archivos suelen tener menos de 256 kb de tamaño, la tabla de la base de datos es la mejor opción
• Si los archivos generalmente tienen más de 1 MB de tamaño, o podrían tener más de 2 GB de tamaño, entonces FileStream (o en su caso: el sistema de archivos antiguo) es su mejor opción
• No hay recomendación para archivos entre esos dos márgenes

Además, para no afectar negativamente el rendimiento de sus consultas, a menudo es una buena idea colocar los archivos grandes en una tabla separada, no haga que las gotas enormes sean parte de sus tablas regulares que consultas, sino crear una Tabla separada, con la que solo consulta, si realmente necesita los megabytes de documentos o imágenes.

¡Entonces eso podría darle una idea de dónde empezar!

Answer 2

Le sugiero encarecidamente que considere la solución del sistema de archivos. Las razones son:

• Tiene un mejor acceso a los archivos (preciosos en caso de depuración), lo que significa que puede usar herramientas regulares basadas en consolas
• Puede aprovechar rápida y fácilmente el sistema operativo para distribuir la carga, por ejemplo, utilizando un sistema de archivos distribuido, agregar redundancia a través de una redada de hardware, etc.
• Puede aprovechar las listas de control de acceso del sistema operativo para hacer cumplir los permisos.
• No obstruye su base de datos

Si le preocupa grandes cantidades de entradas en sus directorios, siempre puede crear un esquema de ramificación. por ejemplo:

filename : hello.txt
filename md5: 2e54144ba487ae25d03a3caba233da71
final filesystem position: /path/2e/54/hello.txt

Answer 3

Hay mucho "depende" de este tema popular. Como dice que los documentos son sensibles y confidenciales, fuera del brazalete, iría con el almacenamiento en la base de datos. Aquí hay algunas razones:

• Potencialmente mejor seguridad. A menudo es más fácil hackear un sistema de archivos que una base de datos.
• Mejor control de volumen. Miles de archivos en una carpeta pueden forzar un sistema operativo, donde una base de datos puede tomar millones de filas en una tabla sin parpadear.
• Mejor búsqueda y escaneo. Agregue columnas de categorización cuando cargue los datos, o pruebe la indexación de texto completo para escanear los documentos reales.
• Las copias de seguridad pueden ser más eficientes: solo agregue otra base de datos a su plan de copia de seguridad y esté cubierto (una vez que resuelva los detalles del espacio, por supuesto). Y esos archivos de copia de seguridad son otra capa de ofuscación en cualquiera que intente obtener sus documentos confidenciales.
• SQL Server 2008 tiene opciones de compresión de datos que pueden ayudar aquí. ¿Eso o la aplicación lo hace? (Más seguridad a través de la ofuscación, tal vez)

SQL Server 2008 también tiene el tipo de datos FileStream, que puede ayudar aquí, pero no estoy lo suficientemente familiarizado como para dar una recomendación para su situación.