performance - tipo - Almacenamiento de documentos como blobs en una base de datos-¿Alguna desventaja?
filestream sql server (8)
Acabo de comenzar a investigar el FILESTREAMing de SQL Server 2008 para BLOB y me he encontrado con una limitación ENORME (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?
Los requisitos para mi sistema de gestión de documentos fueron:
- Debe ser seguro contra el robo mediante la simple copia de directorios, archivos, etc.
- Debe ser seguro contra la infección de virus tradicional (infección de archivo físico)
- Debe ser rápido para recuperar
- El repositorio no debe estar visible para usuarios ocasionales de exploración (directorio), etc.
He decidido almacenar todos los documentos (y las 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 de arriba y hay incluso un par de ventajas adicionales, como la autosturación de documentos junto con la entidad a la que se refiere, la búsqueda fácil y rápida de los contenidos, la eliminación de todo tipo de actividades del usuario en torno a la apertura y el nombramiento de documentos, etc.
Mi pregunta es: ¿hay algún riesgo serio 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.
Cuando su base de datos crezca cada vez más, 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 convierta en un problema mucho después de que golpees una pared con la copia de seguridad del conjunto de datos.
De 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 usa 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.
Depende del tipo de datos. Oracle o SQLServer? Tenga en cuenta una desventaja: restauración de un solo documento.
Desde mi experiencia, algunos problemas fueron:
velocidad vs tener archivos en el sistema de archivos.
almacenamiento en caché IMO, el servidor web hará un mejor trabajo almacenando en caché los contenidos estáticos. El DB también hará un buen trabajo, pero si el DB también está entregando todo tipo de otras consultas, no espere que esos documentos grandes permanezcan en la memoria caché por mucho tiempo. En esencia, tiene que transferir los archivos dos veces. Una vez desde la base de datos al servidor web, y luego al servidor web al cliente.
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 debería ser capaz de manejar la mayoría de sus problemas de seguridad, pero si los documentos son pequeños y la base de datos ya no está cargada, entonces realmente no veo un gran problema con tenerlos en la base de datos.
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 grandes. Parece que ya ha tenido esto en cuenta en su lista de requisitos.
Aquí hay una buena referencia (PDF) que cubre los pros y los contras de los blobs.
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 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 apuntar al usuario a la fuente y salir 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
Permítanme aclarar mi afirmación: con SQL Server tiene opciones limitadas cuando excede 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.