Pregunta de diseño del repositorio de bases de datos de documentos / imágenes

Question

Pregunta:

¿Debo escribir mi aplicación para acceder directamente a un repositorio de imágenes de base de datos o escribir una pieza de middleware para manejar solicitudes de documentos?

Fondo:

Tengo una aplicación personalizada de procesamiento de imágenes y flujo de trabajo que actualmente almacena alrededor de 15 millones de documentos / imágenes de documentos (90% + página única, grupo 4 tiffs, el resto de documentos PDF, Word y Excel). El repositorio de imágenes es una aplicación comercial de terceros que es muy costosa y francamente tiene demasiada sobrecarga. Solo necesito un sistema para almacenar y recuperar imágenes de documentos.

Estoy considerando mover las imágenes directamente a una base de datos de SQL Server 2005. La información de indexación es muy limitada, básicamente 2 campos de índice. Es un sistema de administración de pólizas de seguro de vida, por lo que indizo imágenes con un número de póliza y un número de identificación único para todo el sistema. Hay otros valores de índice, pero se almacenan y mantienen por separado de los datos de la imagen. Esos valores de índice me dan la capacidad de buscar el valor de identificación único para la recuperación de imágenes individuales.

El servidor de la base de datos es una caja de Windows 2003 de doble núcleo cuádruple con unidades SAN que alojan los archivos DB. El tamaño actual del repositorio de imágenes es de aproximadamente 650 GB. No he hecho ninguna prueba para ver qué tan grande será la base de datos convertida. Realmente no estoy preguntando sobre el diseño de la base de datos, estoy trabajando con nuestros DBA en ese aspecto. Si eso cambia, volveré :-)

El sistema actual a ser reemplazado es obviamente una aplicación de middleware, pero es un sistema muy pesado distribuido en 3 servidores de Windows. Si sigo esta ruta, sería un sistema de servidor único.

Mis principales preocupaciones son la escalabilidad y el rendimiento, muy ponderados hacia el rendimiento. Tengo alrededor de 100 usuarios, y el crecimiento del uso probablemente será lento en los próximos años. La mayoría de los usuarios son principalmente usuarios leídos: no agregan imágenes al sistema con mucha frecuencia. Tenemos un departamento que maneja el escaneo y, de lo contrario, agrega imágenes al repositorio. También tenemos algunas otras aplicaciones que reciben documentos (a través de ftp) y los insertan en el repositorio automáticamente a medida que se reciben, ya sea con información de índice completa o como & Quot; lotes & Quot; que un usuario revisa e indexa.

La mayoría (90% +) de los documentos / imágenes son muy pequeños, < 100K, probablemente & Lt; 50K, por lo que creo que el almacenamiento de las imágenes en el archivo de la base de datos será el más eficiente en lugar de obtener SQL 2008 y usar un flujo de archivos.

Answer 1

A menudo, la escalabilidad y el rendimiento se unen entre sí en el sentido de que dentro de seis meses la gerencia regresa y dice " La función Y en la aplicación X se ejecuta inaceptablemente lenta, ¿cómo lo aceleramos? quot; Y con demasiada frecuencia, la respuesta es actualizar la solución de fondo. Y cuando se trata de actualizar back-end, casi siempre será menos costoso escalar que escalar en términos de hardware.

Entonces, para resumir, recomendaría crear una aplicación de middleware que maneje específicamente las solicitudes entrantes de la aplicación del usuario y luego las enrute al destino apropiado. Esto abstraerá suficientemente su aplicación de usuario front-end de la solución de almacenamiento de back-end para que, cuando la escalabilidad se convierta en un problema, solo será necesario actualizar la aplicación de middleware.

Answer 2

Esto es sencillo. Escriba la aplicación en una interfaz, use algún tipo de mecanismo de fábrica para suministrar esa interfaz e implemente esa interfaz como desee.

Una vez que esté satisfecho con su interfaz, la aplicación está (en su mayoría) aislada de la implementación, ya sea que esté hablando directamente a una base de datos o a algún otro componente.

Pensando un poco en el diseño de su interfaz pero haciendo una tontería, & "; es simple, funciona aquí, funciona ahora &"; Las implementaciones ofrecen un buen equilibrio entre las pruebas futuras del sistema y no necesariamente una ingeniería excesiva.

Es fácil argumentar que ni siquiera necesita una interfaz en esta coyuntura, sino solo una clase simple que cree una instancia. Pero si su contrato está bien definido (es decir, la interfaz o la firma de la clase), eso es lo que lo protege del cambio (como rehacer la implementación del back-end). Siempre puede reemplazar la clase con una interfaz más adelante si lo considera necesario.

En cuanto a la escalabilidad, pruébelo. Entonces sabes no solo si necesitas escalar, sino quizás cuándo también. " Funciona muy bien para 100 usuarios, problemático para 200, si llegamos a 150 podríamos considerar echar un vistazo al back-end, pero es bueno por ahora. "

Esa es la debida diligencia y una táctica de diseño responsable, en mi humilde opinión.

Answer 3

Estoy de acuerdo con gabriel1836. Sin embargo, un beneficio adicional sería que por un tiempo podría ejecutar un sistema híbrido por un tiempo, ya que no va a convertir 14 millones de documentos de su sistema propietario a su sistema de producción propia durante la noche.

Además, le recomiendo encarecidamente que almacene los documentos fuera de una base de datos. Almacénelos en un sistema de archivos (local, SAN, NAS, no importa) y almacene punteros a los documentos en la base de datos.

Me encantaría saber qué sistema de gestión de documentos está utilizando ahora.

Además, no subestimes el esfuerzo de reemplazar la captura (escaneo e importación) proporcionada por el sistema propietario.