database - tipo - subir archivos a sql server

¿Ubicación recomendada para el almacenamiento de documentos, en la base de datos o en otro lugar? (13)

Fondo:

Tenemos un sistema interno de almacenamiento de documentos que se implementó hace mucho tiempo. Por el motivo que sea, se eligió usar la base de datos como mecanismo de almacenamiento para los documentos.

Mi pregunta es esta:

¿Cuál es la mejor práctica para almacenar documentos? ¿Cuáles son las alternativas? ¿Cuáles son los pros y los contras? Las respuestas no tienen por qué ser específicas de la tecnología o la plataforma, sino más bien una pregunta general sobre las mejores prácticas.

Mis pensamientos:

Las bases de datos no son para el almacenamiento de documentos. File Systems o sistemas de gestión de documentos de terceros pueden ser de mejor uso. El almacenamiento de documentos en bases de datos es costoso. Las operaciones son lentas ¿Son estas suposiciones lógicas? Tal vez esto sea lo mejor, pero en mi opinión, tenemos mejores alternativas. ¿Podría Oracle BFILE (enlaces a documentos en NAS o SAN) ser mejor que BLOB / CLOB?

Detalles:

Los documentos son de varios tipos (pdf, word, xml)
El código de nivel medio está escrito en .net 2.0 / c #
Los documentos se almacenan en una base de datos Oracle 10g en BLOB con compresión (Almacenamiento NAS)
Tamaño de archivo de ira
El número de documentos está creciendo drásticamente y no tiene signos de desaceleración
Los insertos normalmente se encuentran en hunderds por hora durante el pico
Retreival es típicamente de miles por hora durante el pico
El almacenamiento NAS y el almacenamiento SAN están disponibles

ACTUALIZACIÓN (de las preguntas a continuación):

mi fondo es el desarrollo
hay metadatos asociados sobre los archivos almacenados al lado del archivo en la base de datos

Almacene los archivos binarios en el sistema de archivos. Cree una aplicación ASP.NET para las operaciones de almacenamiento y recuperación. Puede ser elegante con la aplicación web (versiones de documentos, seguridad de varios niveles, etc.). Creo que este es el consenso en la industria de gestión de documentos.

Dado que su "número de documentos está creciendo drásticamente", parece que se está convirtiendo en una gran escala. Es posible que desee comenzar a buscar soluciones externas listas para usar (como http://kofax.com/capture/ - ¡Tengo una amplia experiencia en esto!) Para hacer el "trabajo sucio" para tú. O mejor aún, considere buscar ofertas de SaaS como estas personas http://www.edocumentsolutionsllc.com/

:-)

Almacene sus documentos como archivos como .doc si desea poder acceder a los archivos y editarlos y volver a guardarlos.

Almacene sus documentos como archivos como .pdf o .tiff si desea copias históricas reales que puedan extraerse y reproducirse.

Almacene toda la información relativa a sus archivos (como fechas, autores, ubicación) en su base de datos.

Considere almacenar sus documentos en subversión u otro sistema de control de versiones. Tendrá una buena copia de seguridad, la capacidad de mirar versiones antiguas de documentos y un espléndido acceso a la red. Ver " Mi vida en subversión ".

Experiencia personal: ¿Eres un administrador de DB o un programador?

Seguridad: una configuración para la base de datos frente a 2 para la base de datos y el sistema de archivos. ¿Le preocupa a alguien mover / eliminar accidentalmente los archivos? En una configuración compleja, un administrador puede elegir mover los archivos a otro servidor y simplemente cambiar el Compartir o el mapeo. Lo sé, esto nunca sucederá.

Nuevas bases de datos están mejorando en esta área.

He almacenado imágenes como BLOB en la base de datos una vez y lamenté la primera vez que tuve que realizar una operación por lotes en esas imágenes. Hubiera sido mucho más fácil hacerlo en el sistema de archivos. Además, como mencionó, es mucho más rápido recuperar los documentos si viven en un sistema de archivos.

Mi simple vista: el sistema de archivos debe almacenar archivos, y una base de datos relacional debe almacenar datos relacionales.

La única ventaja que puedo ver al almacenar documentos en la base de datos es la facilidad de mover esos documentos a otro entorno. Aparte de eso, no lo haría por todas las razones ya mencionadas.

Mi principal preocupación al almacenar los archivos en la base de datos es administrar el tamaño y la complejidad de las copias de seguridad y otras operaciones de mantenimiento de db.

Una estrategia para mitigar esta dificultad (al menos en MS SQL) es crear particiones de bases de datos separadas, potencialmente almacenadas en diferentes unidades.

Luego, separe su esquema de datos para que sus metadatos sobre los archivos se encuentren en una partición, y los archivos BLOB reales se encuentren en una partición separada.

Estas particiones pueden respaldarse en diferentes programaciones, o incluso recuperarse por separado.

Prefiero almacenar el documento en el sistema de archivos y luego almacenar un enlace al archivo y los metadatos del archivo asociado en la base de datos .

Ha demostrado ser más conveniente, más fácil de mantener y menos costoso que la alternativa.

Según mi experiencia, les digo que los mantengan en la base de datos. Hemos movido dos de nuestros sistemas para hacer esto.

Ponerlo en la base de datos significa:

Es de fácil acceso, incluso desde múltiples servidores
Se realiza una copia de seguridad automáticamente (en lugar de tener que tener un trabajo separado para hacerlo)
No tiene que preocuparse por el espacio (ya que las personas evitan que el DB llene demasiado el disco, pero pueden olvidarse de controlar dónde se almacenan los documentos)
No es necesario que tenga un esquema de directorio complicado

Teníamos documentos fuera de la base de datos. Se convierte en un problema con muchos documentos. Un directorio normal en Linux es un bloque, que generalmente es 4K. Teníamos un directorio de 58MB porque tenía tantos archivos (era solo un directorio plano, sin jerarquía). Tenía tantos bloques indirectos. Tomó más de una hora para eliminar. Tardó unos minutos en contar el número de archivos en el directorio. Fue abismal. Esto está en ext3.

Con el sistema de archivos que necesita:

Mecanismo de copia de seguridad separado (de la copia de seguridad de la base de datos)
Para mantener las cosas sincronizadas (para que el registro no exista en el DB sin que el archivo esté allí)
Una jerarquía para el almacenamiento (para evitar el problema mencionado anteriormente, por lo que ningún directorio termina con 10.000 de archivos)
Una forma de verlos desde otros servidores si necesita un clúster (probablemente NFS o algo así)

Es realmente un dolor. Para cualquier número no trivial de documentos, recomendaría en contra del sistema de archivos basado en lo que he visto.

Siempre guardo la información del núcleo y la ruta del archivo para los documentos en la base de datos, pero nunca el documento en sí. Raramente, todo el documento debe estar en la base de datos.

Esto permite mucha más flexibilidad en el uso de esos documentos. Por ejemplo, ¿desea utilizar los mecanismos de almacenamiento de copia de seguridad por niveles y deduping? Pruébalo en Oracle BLOBs.

El único límite para almacenar documentos en la base de datos es tecnológico.

Una base de datos de relaciones pretende ser el almacenamiento permanente de los datos de misión crítica de una empresa. Qué tan bien puede realizar esa función varía de base de datos a base de datos y sistema a sistema, por supuesto. Pero, idealmente, las propiedades ACID de una base de datos relacional están destinadas a convertirlo en el almacén de todos los datos empresariales . El sistema de archivos, los sistemas de controlador de revisiones y otros sistemas de almacenamiento de tiendas locales pueden tener ventajas específicas, pero no están diseñados para el almacenamiento de datos de la empresa como tal.

Si los documentos que está almacenando califican como datos de la empresa, si se usan persistentemente en toda la empresa, entonces es lógico mantenerlos en la base de datos. Si tiene problemas para almacenar en la base de datos, quizás un DBA pueda encontrar una mejor solución. Incluso podría tener que sacarlos de la base de datos por razones de rendimiento, pero no creo que deba sacarlos de la base de datos por motivos de buenas prácticas.

Por supuesto, si los documentos no son datos empresariales, si solo se usan para una aplicación, por ejemplo, moverlos fuera de la base de datos también tendría sentido.

La mayoría de los sistemas de gestión de documentos de clase empresarial NO almacenan el archivo objeto en la base de datos. El hecho de que puedas no significa que debas . Si la escalabilidad y el rendimiento son importantes para usted y tiene un gran conjunto de documentos, debe tener mucho cuidado con el almacenamiento de los objetos en el DB. Considera lo siguiente:

En el caso de las imágenes de documentos, 200 millones de archivos TIFF pueden considerarse un sistema relativamente grande, pero no masivo. Los sistemas de mayor escala pueden tener más de mil millones de archivos de objetos. En, digamos, 20 KB por bitonal TIFF, podría tener 4 TB de almacenamiento de archivos de objetos. ¿Cuánto tiempo durarán las copias de seguridad de su base de datos? ¿Cuánto tiempo van a tomar sus consultas? ¿Cuál es la frecuencia de acceso para estos objetos? Si estos objetos tienen una alta frecuencia de acceso, ¿quiere que su servidor de base de datos de alto nivel dedique todo su tiempo a servir archivos? Si tiene millones de objetos, debe ser muy cuidadoso con la forma de diseñar una solución donde los objetos se almacenan en la base de datos.

Supongamos que ahora tiene la tarea de convertir esos archivos 200M TIFF a archivos PDF. Prepárese para poner su solución de rodillas, ya que su servidor de base de datos pierde su tiempo en servir todos y cada uno de los archivos de objetos al proceso de conversión y luego volver a guardar los resultados.

Solo a modo de ejemplo, Sharepoint es famoso por almacenar objetos en el db. Sharepoint también es famoso por problemas de escalabilidad.

Mi respuesta:
Para sistemas pequeños (<1M), se pueden considerar el almacenamiento de archivos en el DB. Para sistemas grandes (> 1M), almacenar archivos en la base de datos es un error.

Por el contrario, buscaría almacenamiento en la base de datos por un par de razones:

Estrategia de copia de seguridad más simple
Los documentos almacenados en la base de datos se pueden indexar y buscar
No tiene que preocuparse por los archivos que se mueven / seguridad manipulada
Fácil de portar a otro servidor en caso de un bloqueo
Si el gobierno ordena que debe almacenar datos que datan de hace x años, es mucho más fácil administrarlo utilizando una base de datos.

Las bases de datos están hechas para almacenar datos. Los archivos son solo datos.

A pesar de haber dicho que existen beneficios al almacenar archivos en el sistema de archivos, el principal es que el rendimiento de la base de datos es mejor y el tamaño se mantiene bajo. SQL Server 2008 le permite tener lo mejor de ambos mundos usando FileStream. Lea este documento técnico para obtener más información