Document Storage Repository - Open Source / Design Pattern

Question

Document Storage Repository - Open Source / Design Pattern

#1 da (1 voti)
#2 da (0 voti)

3

Al momento ho diverse applicazioni Web che offrono il caricamento e l'archiviazione dei documenti. Ora sto cercando di creare un servizio centrale di gestione dei documenti che queste applicazioni possano sfruttare per archiviare e recuperare questi documenti. Attualmente i documenti sono archiviati su disco. Il nome del file è un Guid e il suo vero nome e tipo di dati sono memorizzati in un database.

Sto seguendo l'approccio giusto in base al quale ho una tabella di database che memorizza le informazioni dei documenti (Nome, ContentType, CreatedDate, CreatedBy, SystemId ecc.) e quindi memorizzo il documento in una cartella sul file system locale del server?

Quando ho iniziato a memorizzare i documenti, erano originariamente dei BLOB nel database. Questo ho trovato un approccio sfavorevole. Il mio database è stato improvvisamente MASSICCIO e impossibile da eseguire il backup e il ripristino. Separando i documenti nel file system locale il database è ora molto più semplice e la mia strategia di backup è più semplice. (Database di backup, backup di file diff dalla cartella)

C'è un modo più sensato per fare ciò che mi manca? C'è qualche progetto open source che posso sfruttare per migliorare il design del mio nuovo servizio che sto creando da zero?

design-patterns soa

posta WebDude 06.08.2013 - 07:40

fonte

2 risposte

Leggi altre domande sui tag design-patterns soa

Il modo migliore per testare un servizio web reimplementato Esiste un nome per un heap randomizzato?

score 1 · Answer 1

Questo è probabilmente l'approccio migliore.

La mia unica avvertenza è che devi pensare al backup e al ripristino degli errori dei tuoi file di documento.

L'archiviazione di due copie su dischi separati fornirebbe all'incirca la stessa recuperabilità di un blob nel database.

score 0 · Answer 2

A seconda delle dimensioni della tua azienda, a mano a mano che aumentano le esigenze del tuo sistema di gestione dei contenuti, potresti aver bisogno di più istanze e quindi la tua architettura dovrebbe essere progettata in modo tale da mirare non solo all'ID di un documento, ma alla gestione dei contenuti istanza di istanza per cui risiede.

Gli utenti del servizio non dovrebbero preoccuparsi di questo dettaglio del routing, comunque. Architetto una soluzione in cui si dispone di una sorta di motore di regole che individua la migliore istanza da utilizzare per archiviare il documento. Potrebbe essere basato su una sorta di processo di raccolta o monitoraggio delle statistiche (forse anche un altro schema) in modo da utilizzare il percorso di routing più efficiente.

Il punto è che questo "sistema di routing" è disaccoppiato dall'istanza del sistema di gestione dei contenuti E dai client che li utilizzano, consentendo di mantenere lo schema di routing senza troppe interruzioni agli utenti o alle istanze del sistema di gestione dei contenuti.

Poiché il processo di gestione dei documenti viene eseguito per un lungo periodo di tempo, avrai un'idea migliore di quali regole applicare per il routing, eventualmente modificando il tuo motore di regole.

Il tuo guid verrebbe quindi creato dal tuo sistema di routing, non dal sistema di gestione dei contenuti (ad esempio, docid + ":" + instanceid). Il database del sistema di routing che memorizza i metadati dovrebbe disporre di informazioni sufficienti che possono essere utilizzate per supportare le future modifiche al motore delle regole (per farlo funzionare in modo ancora più efficiente)