Domanda di progettazione del repository di database di documenti / immagini

Question

Domanda:

Devo scrivere la mia applicazione per accedere direttamente a un repository di immagini del database o scrivere un pezzo di middleware per gestire le richieste di documenti.

Sfondo:

Ho un'applicazione Document Imaging e Workflow personalizzata che attualmente memorizza circa 15 milioni di documenti / immagini di documenti (90% + pagina singola, gruppo 4 tiffs, il resto documenti PDF, Word ed Excel). Il repository di immagini è un'applicazione commerciale di terze parti che è molto costosa e francamente ha un sovraccarico eccessivo. Ho solo bisogno di un sistema per archiviare e recuperare immagini di documenti.

Sto considerando di spostare l'immagine direttamente in un database di SQL Server 2005. Le informazioni di indicizzazione sono molto limitate, sostanzialmente 2 campi indice. È un sistema di gestione delle polizze assicurative sulla vita, quindi indicizzo le immagini con un numero di polizza e un numero ID univoco a livello di sistema. Esistono altri valori di indice, ma vengono memorizzati e gestiti separatamente dai dati dell'immagine. Quei valori di indice mi danno la possibilità di cercare il valore ID univoco per il recupero di singole immagini.

Il server database è un box Windows 2003 dual-quad core con unità SAN che ospitano i file DB. L'attuale dimensione del repository di immagini è di circa 650 GB. Non ho fatto alcun test per vedere quanto sarà grande il database convertito. Non sto davvero chiedendo la progettazione del database - sto lavorando con i nostri DBA su questo aspetto. Se ciò cambia, tornerò :-)

L'attuale sistema da sostituire è ovviamente un'applicazione middleware, ma è un sistema molto pesante distribuito su 3 server Windows. Se seguissi questa strada, sarebbe un sistema a server singolo.

Le mie preoccupazioni principali sono la scalabità e le prestazioni - fortemente ponderate per le prestazioni. Ho circa 100 utenti e la crescita dell'utilizzo sarà probabilmente lenta per i prossimi anni. La maggior parte degli utenti sono principalmente utenti di lettura: non aggiungono immagini al sistema molto spesso. Abbiamo un dipartimento che gestisce la scansione e altrimenti l'aggiunta di immagini al repository. Abbiamo anche alcune altre applicazioni che ricevono documenti (tramite ftp) e li inseriscono automaticamente nel repository man mano che vengono ricevuti, o forniranno informazioni complete sull'indice o come & Quot; batch & Quot; che un utente rivede e indicizza.

La maggior parte (90% +) dei documenti / immagini è molto piccola, < 100K, probabilmente & Lt; 50 KB, quindi credo che l'archiviazione delle immagini nel file di database sia la più efficiente anziché ottenere SQL 2008 e utilizzare un filestream.

Answer 1

Spesso la scalabilità e le prestazioni alla fine si sposano l'una con l'altra, nel senso che tra sei mesi la gestione torna e dice " La funzione Y nell'applicazione X funziona in modo inaccettabilmente lento, come possiamo accelerarla? quot; E troppo spesso la risposta è aggiornare la soluzione di back-end. E quando si tratta di aggiornare i back-end, è quasi sempre meno costoso ridimensionare che ridimensionare in termini di hardware.

Quindi, per farla breve, consiglierei di creare un'app middleware che gestisca in modo specifico le richieste in arrivo dall'app utente e quindi le instrada alla destinazione appropriata. Ciò renderà sufficientemente astratta la tua app per l'utente front-end dalla soluzione di archiviazione back-end in modo tale che quando la scalabilità diventa un problema, sarà necessario aggiornare solo l'app middleware.

Answer 2

Questo è semplice. Scrivi l'applicazione su un'interfaccia, usa un qualche tipo di meccanismo di fabbrica per fornire quell'interfaccia e implementa quell'interfaccia come preferisci.

Una volta che sei soddisfatto della tua interfaccia, l'applicazione è (principalmente) isolata dall'implementazione, sia che parli direttamente con un DB o con qualche altro componente.

Pensando un po 'avanti al design della tua interfaccia, ma facendo stupido osso, " è semplice, funziona qui, ora funziona! " le implementazioni offrono un buon equilibrio tra il futuro e il sistema, senza necessariamente sovrastarlo.

È facile sostenere che in questo frangente non hai nemmeno bisogno di un'interfaccia, piuttosto di una semplice classe di cui hai un'istanza. Ma se il tuo contratto è ben definito (cioè l'interfaccia o la firma della classe), questo è ciò che ti protegge dal cambiamento (come rifare l'implementazione del back-end). Puoi sempre sostituire la classe con un'interfaccia in un secondo momento se lo ritieni necessario.

Per quanto riguarda la scalabilità, testalo. Quindi sai non solo se potresti aver bisogno di ridimensionare, ma forse anche quando. " Funziona alla grande per 100 utenti, problematico per 200, se colpiamo 150 potremmo considerare di dare un'altra occhiata al back-end, ma per ora va bene. "

Questa è la dovuta diligenza e una tattica di progettazione responsabile, IMHO.

Answer 3

Sono d'accordo con gabriel1836. Tuttavia, un ulteriore vantaggio sarebbe che potresti per un certo periodo eseguire un sistema ibrido per un certo periodo poiché non convertirai 14 milioni di documenti dal tuo sistema proprietario al tuo sistema domestico durante la notte.

Inoltre, ti incoraggio vivamente a conservare i documenti al di fuori di un database. Archiviarli su un file system (locale, SAN, NAS non importa) e archiviare i puntatori ai documenti nel database.

Mi piacerebbe sapere quale sistema di gestione dei documenti stai utilizzando ora.

Inoltre, non sottovalutare lo sforzo di sostituire l'acquisizione (scansione e importazione) fornita dal sistema proprietario.