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

Question

Antecedentes:

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 la siguiente:

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

Mis Pensamientos:

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:

• Documentos varios tipos (pdf, word, xml)
• El código de etapa intermedia está escrito en .NET 2.0/C#
• documentos se almacenan en un Oracle 10g base de datos en BLOB con compresión (Almacenamiento NAS)
• Tamaño de archivo rabia
• El número de documentos está creciendo drásticamente y no tiene signos de desaceleración
• Inserciones es normalmente se encuentra en los hunderds por hora durante el pico
• retreival está típicamente en los miles por hora durante el pico
• de almacenamiento NAS y SAN de almacenamiento está disponible

ACTUALIZACIÓN (a partir de las siguientes preguntas):

• mi fuerte es el desarrollo
• se asocia meta-datos sobre los archivos almacenados junto a los archivos de la base de datos

Answer 1

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

A relation database está destinado a 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 relational database son previsto para que sea la tienda de todos enterprise data. 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.

Answer 2

prefiero almacenar el documento en el sistema de archivos y luego tienda de un enlace al archivo y meta-datos 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.

Answer 3

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.

Answer 4

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 vista simple: el sistema de archivos debe almacenar archivos, y una base de datos relacional debe almacenar datos relacionales.

Answer 5

Siempre almaceno 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.

Answer 6

De acuerdo con mi experiencia, yo diría que los mantienen en la base de datos. Hemos movido dos de nuestros sistemas para hacer esto.

Ponerlo en la base de datos significa:

• Es fácil acceso, incluso desde varios servidores
• está respaldado de forma automática (en lugar de tener que tener un trabajo independiente para hacer eso)
• Usted no tiene que preocuparse por el espacio (ya que las personas evitan que el DB llene demasiado el disco, pero puede olvidarse de monitorear dónde se almacenan los documentos)
• No necesita tener 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 que era 58MB porque tenía tantos archivos (era solo un directorio plano, sin jerarquía). Tenía que muchos 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 independiente (de la copia de seguridad DB)
• para mantener las cosas en sincronía (por lo que el registro no existe en la base de datos sin el archivo de estar allí)
• Una jerarquía para el almacenamiento (para evitar el problema mencionado anteriormente, por lo que ningún directorio termina con 10,000s de archivos)
• Alguna manera 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.

Answer 7

La única ventaja que puedo ver para 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.

Answer 8

Por el contrario iría para su almacenamiento en la base de datos por un par de razones:

1. más simple estrategia de copia de seguridad
2. documentos almacenados en la base de datos se pueden indexar y buscar
3. Usted no lo hace tiene que preocuparse por los archivos que se mueven/la seguridad manipulada con
4. Fácil de portar a otro servidor en el caso de un bloqueo
5. Si el gobierno exige que debe almacenar datos que datan de hace x años, administrar esto usando una base de datos es mucho más fácil

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

Aunque he dicho que hay beneficios en el almacenamiento de 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. Read this whitepaper para más información

Answer 9

Mi mayor preocupación con el almacenamiento de los archivos en la base de datos es la gestión del 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 unidades diferentes.

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

Estas particiones se pueden respaldar en diferentes programaciones, o incluso se pueden recuperar por separado.

Answer 10

Experiencia personal: ¿Es usted un administrador de DB o un programador?

Seguridad: una configuración para la base de datos contra 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á.

Las nuevas bases de datos están mejorando en esta área.

Answer 11

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 usted. O mejor aún, considerar la búsqueda de SaaS que ofrece, tales como estos chicos http://www.edocumentsolutionsllc.com/

:-)

Answer 12

considere almacenar sus documentos en la 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 "My life on subversion".

Answer 13

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 puede no significa que debería. 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. Considere 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, ¿desea que su servidor de base de datos de alto nivel dedique todo su tiempo a servir los 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 archivo 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 la base de datos. Para sistemas grandes (> archivos de 1M), almacenar archivos en la base de datos es un error.