Almacenamiento de documentos como blobs en una base de datos - ¿Alguna desventaja?

Question

Los requisitos para mi sistema de gestión de documentos fueron:

1. debe estar seguro de hurto por simple copia de los directorios, archivos, etc.
2. debe ser segura contra la infección de virus tradicionales (infección del archivo físico)
3. debe ser rápido para recuperar
4. El repositorio no debe ser visible a lo casual (directorio) usuarios leyendo etc.

he decidido Stor Todos los documentos (e imágenes escaneadas) como blobs en la base de datos y hasta ahora mi experiencia es maravillosa y la recuperación de documentos también es deslumbrante: cumple con todos los criterios anteriores e incluso hay algunas ventajas adicionales, como la autoestimación de documentos junto con la entidad con la que se relaciona, búsqueda fácil y rápida de contenidos, eliminación de todo tipo de actividades del usuario en torno a la apertura y el nombramiento de documentos, etc.

Mi pregunta es: ¿hay riesgos graves o cosas que pasé por alto? con este diseño e implementación?

EDITAR Nota: DB es PostgreSQL, maneja BLOBS muy bien y escalas excepcionalmente bien. El entorno es multiusuario.

Answer 1

Cuando su base de datos crece cada vez más grande, será más difícil realizar una copia de seguridad. Restaurar una copia de seguridad de una tabla con más de 100 GB de datos no es algo que lo haga feliz.

Otra cosa que se obtiene es que todas las funciones de administración de tablas se vuelven cada vez más lentas a medida que crece el conjunto de datos.
Pero esto puede superarse haciendo que su tabla de datos solo contenga 2 campos: ID y BLOB.

Recuperar datos (por clave principal) probablemente solo se convertirá en un problema mucho después de que golpee una pared con la copia de seguridad del conjunto de datos.

Answer 2

Este article cubre la mayoría de los problemas. Si está utilizando SQL Server 2008, revise el uso del nuevo tipo de FILESTREAM según lo discutido por Paul Randal here.

Answer 3

La principal desventaja que suelo escuchar al usar blobs es que, por encima de cierto tamaño, el sistema de archivos es mucho más eficiente para almacenar y recuperar archivos de gran tamaño. Parece que ya lo ha tenido en cuenta en su lista de requisitos.

Hay un good reference (PDF) here que cubre los pros y los contras de los blobs.

Answer 4

Lo siento, la respuesta que ofrecí estaba basada en SQL Server, por lo que la parte de mantenimiento no es adecuada. Pero la E/S de archivos se lleva a cabo en el nivel de hardware y cualquier base de datos agrega pasos de procesamiento adicionales.

La base de datos impondrá gastos indirectos adicionales al recuperar el documento. Cuando el archivo está en el disco, solo es tan lento o tan rápido como la E/S en el servidor. Sin duda debe administrar su meta en una base de datos, pero al final desea que el UNC del archivo y apunte al usuario a la fuente y salga del camino.

Desde una perspectiva de mantenimiento y administración, se limitará a una SAN cuando trabaje con MS SQL Server. Las soluciones como Documentum adoptan un enfoque diferente con un simple almacenamiento en el disco y le permite implementar una solución de almacenamiento como mejor le parezca.

EDITAR

Aclaro mi estado de cuenta - con SQL Server que tienen opciones limitadas en caso de sobrepasar la capacidad de almacenamiento físico de la caja. Esta es, de hecho, una de las grandes debilidades de Sharepoint por la que no puede adjuntar simplemente cualquier tipo de almacenamiento en red.

Answer 5

Depende del tipo de datos. Oracle o SQLServer? Tenga en cuenta una desventaja: restauración de un solo documento.

Answer 6

Desde mi experiencia, algunos temas fueron:

1. velocidad vs tener los archivos en el sistema de archivos.

2. almacenamiento en caché. IMO, el servidor web hará un mejor trabajo almacenando en caché contenido estático. El DB también realizará un buen trabajo , pero si el DB también es entregando todo tipo de consultas, no espere que esos documentos grandes permanezcan en la memoria caché por mucho tiempo. Usted esencialmente tiene que transferir los archivos dos veces. Una vez desde la base de datos al servidor web , y luego al servidor web al cliente .

3. Limitaciones de memoria. En mi último trabajo teníamos un PDF de 40MB en la base de datos, y seguía obteniendo Java OutOfMemoryErrors en el archivo de registro. Eventualmente nos dimos cuenta de que todo el PDF de 80MB fue leído en el montón no solo una vez, sino DOS VECES gracias a una configuración en Hibernate ORM (si un objeto es mutable, hace una copia para editar en la memoria). Una vez que el PDF se volvió a transmitir al usuario, se limpió el montón, pero fue un gran golpe sacar 80MB del montón de una vez solo para transmitir un documento. ¡Conozca su código y cómo se usa la memoria!

Su servidor web debe ser capaz de manejar la mayoría de sus problemas de seguridad, pero si los documentos son pequeñas y el PP no está ya bajo una gran carga, entonces yo no ver realmente un gran problema con tener ellos en el DB.

Answer 7

Acabo de empezar a investigar el FILESTREAMing de SQL Server 2008 para BLOB y me he encontrado con una enorme limitación (IMO): solo funciona con seguridad integrada. Si no usa la Autenticación de Windows para conectarse al servidor de BD, no podrá leer/escribir los BLOB. Muchos entornos de aplicaciones no pueden usar la autenticación de Windows. Ciertamente no en ambientes heterogéneos.

Debe existir una mejor solución para almacenar BLOB. ¿Cuáles son las mejores prácticas?

Answer 8

Según lo que he experimentado al almacenar archivos de contenido como blobs, tanto en SQL Server como en Oracle, funciona bien con una base de datos pequeña y con un número bajo de usuarios conectados. El sistema ECM los separa y utiliza servicios separados para transmitir contenido. Dependiendo del tamaño de los archivos, los recursos del servidor pueden verse afectados con la recuperación simultánea de archivos de gran tamaño. El archivo de bases de datos con grandes conjuntos de archivos se vuelve problemático debido al tiempo de restauración y la incapacidad de recuperar documentos del archivo.

Si estos archivos son registros corporativos, y esta es la copia autorizada de los registros, puede tener problemas de administración de cumplimiento y retención, especialmente si archiva los archivos. Además, la búsqueda y el control de versiones pueden convertirse en un gran problema para seguir adelante.

Es posible que desee investigar un sistema ECM con una API de algún tipo, en lugar de reinventar la rueda.