Almacenar documentos como blobs en una base de datos: ¿alguna desventaja?

StackOverflow https://stackoverflow.com/questions/211895

Pregunta

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

  1. Debe estar protegido contra robos mediante la simple copia de directorios, archivos, etc.
  2. Debe estar seguro contra la infección por virus tradicional (infección del archivo físico)
  3. Debe ser rápido para recuperar
  4. El repositorio no debe ser visible para los usuarios ocasionales de navegación (directorio), etc.

Decidí almacenar 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 increíblemente rápida: cumple con todos los criterios de arriba e incluso hay un par de ventajas adicionales, como el almacenamiento automático de documentos junto con la entidad con la que se relaciona, la búsqueda fácil y rápida de contenidos, la eliminación de todo tipo de actividades de los usuarios en torno a la apertura y el nombramiento de documentos, etc., etc.

Mi pregunta es: ¿hay riesgos o cosas serias que haya pasado por alto con este diseño e implementación?

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

¿Fue útil?

Solución

Cuando su base de datos crezca más y más, será más difícil hacer copias 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 se puede superar haciendo que su tabla de datos solo contenga 2 campos:  ID y BLOB.

Es probable que la recuperación de datos (por clave principal) solo se convierta en un problema mucho después de chocar contra una pared al hacer una copia de seguridad del conjunto de datos.

Otros consejos

La principal desventaja que a menudo escucho sobre el uso de blobs es que, por encima de cierto tamaño, el sistema de archivos es mucho más eficiente para almacenar y recuperar archivos grandes. Parece que ya has tomado esto en cuenta por tu lista de requisitos.

Hay una buena referencia (PDF) aquí que cubre los profesionales y contras de blobs.

Desde mi experiencia, algunos problemas fueron:

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

  2. almacenamiento en caché. OMI el servidor web hará un mejor trabajo de almacenamiento en caché contenidos estáticos El DB hará un buen trabajo también, pero si el DB es también dando todo tipo de otras consultas, no esperes esos grandes documentos permanecer en caché por mucho tiempo. Tú esencialmente tienen que transferir la archivos dos veces. Una vez desde el DB al Servidor web, y luego servidor web para cliente.

  3. Restricciones de memoria. En mi último trabajo teníamos un PDF de 40 MB en la base de datos y seguíamos obteniendo Java OutOfMemoryErrors en el archivo de registro. Finalmente, nos dimos cuenta de que todo el PDF de 80 MB se leyó 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 transmitió de nuevo al usuario, se limpió el montón, pero fue un gran golpe chupar 80 MB del montón a la vez solo para transmitir un documento. ¡Conozca su código y cómo se usa la memoria!

Su servidor web debería poder manejar la mayoría de sus preocupaciones de seguridad, pero si los documentos son pequeños y la base de datos no está bajo una gran carga, entonces realmente no veo un gran problema con tenerlos en la base de datos .

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

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

Este artículo cubre La mayoría de los problemas. Si está utilizando SQL Server 2008, verifique el uso del nuevo tipo de FILESTREAM como lo discutió Paul Randal here .

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

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

La base de datos impondrá una sobrecarga adicional al recuperar el documento. Cuando el archivo está en el disco, es tan lento o tan rápido como la E / S en el servidor. Ciertamente, debe administrar su meta en una base de datos, pero al final desea que el UNC del archivo y el usuario apunte a la fuente y sal 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 almacenamiento simple en el disco y le permite implementar una solución de almacenamiento como mejor le parezca.

EDIT

Permítanme aclarar mi afirmación: con SQL Server tiene opciones limitadas cuando excede la capacidad de almacenamiento físico de la caja. De hecho, esta es una de las grandes debilidades de Sharepoint: no puede simplemente adjuntar ningún tipo de almacenamiento de red.

Por lo que he experimentado al almacenar archivos de contenido como blobs, tanto en SQL Server como en Oracle, funciona bien con una pequeña base de datos y con un bajo número de usuarios registrados. El sistema ECM los separa y utiliza servicios separados para la transmisión de contenido. Dependiendo del tamaño de los archivos, los recursos del servidor pueden verse afectados con la recuperación simultánea de archivos grandes. 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, es posible que tenga problemas de cumplimiento y administración de retención, especialmente si archiva los archivos. Además, la búsqueda y el control de versiones pueden convertirse en un gran problema para el futuro.

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

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top