Dokument / Bild-Datenbank-Repository-Design-Frage

Question

Frage:

Soll ich schreibe meine Anwendung direkt eine Datenbank Bild Repository zugreifen oder ein Middleware-Stück schreiben, um Dokument-Anfragen zu bearbeiten.

Hintergrund:

Ich habe eine benutzerdefinierte Document Imaging und Workflow-Anwendung, die über 15 Millionen Dokumente / Dokumentenbilder (90% + einzelne Seite, Gruppe 4 tiffs, der Rest PDF, Word und Excel-Dokumente) zur Zeit speichert. Die Image-Repository ist eine kommerzielle, 3rd-Party-Anwendung, die sehr teuer ist und ehrlich gesagt zu viel Overhead hat. Ich brauche nur ein System zum Speichern und Dokumentenbilder abgerufen werden.

Ich betrachte die Abbildung direkt in eine SQL Server 2005-Datenbank zu bewegen. Die Indexinformationen sind sehr begrenzt - im Grunde zwei Indexfelder. Es ist eine Lebensversicherung Verwaltungssystem so I Indexbilder mit einer Policennummer und einer systemweit eindeutige ID-Nummer. Es gibt auch andere Indexwerte, aber sie sind gespeichert und getrennt von den Bilddaten beibehalten. Diese Indexwerte geben mir die Möglichkeit, den eindeutigen ID-Wertes für einzelne Bildsuche Suche.

Der Datenbankserver ist ein Dual-Quad-Core-Windows 2003 Box mit SAN-Laufwerken der DB-Dateien hosten. Die aktuelle Bild Repository Größe etwa 650GB. Ich habe noch keine Tests, um zu sehen getan, wie groß die konvertierte Datenbank sein wird. Ich frage nicht wirklich über die Datenbank-Design - ich bin mit unserer DBAs auf diesen Aspekt zu arbeiten. Wenn sich das ändert, werde ich wieder: -)

Das derzeitige System ersetzt werden soll offensichtlich eine Middleware-Anwendung, aber es ist ein sehr Schwergewicht System verteilt auf 3 Windows-Server. Wenn ich diesen Weg zu gehen, wäre es ein einziges Server-System sein.

Meine primäre Anliegen sind scalabity und Performace - stark auf die Leistung gewichtet. Ich habe etwa 100 Nutzer und Nutzungswachstum wird wahrscheinlich in den nächsten Jahren langsam sein. Die meisten Benutzer werden in erster Linie Benutzer lesen - sie fügen Sie keine Bilder, die auf dem System sehr oft. Wir haben eine Abteilung, die das Scannen und ansonsten das Hinzufügen von Bildern in das Repository verarbeitet. Wir haben auch einige andere Anwendungen, die Dokumente (via FTP) empfangen und sie fügen Sie sie in das Repository automatisch wie sie empfangen werden, entweder wird die volle Indexinformationen oder als „Chargen“, dass ein User-Bewertungen und Indizes.

Die meisten (90% +) der Dokumente / Bilder sind sehr klein, <100K, wahrscheinlich <50K, so glaube ich, dass die Speicherung der Bilder in der Datenbank-Datei wird die effizienteste und nicht als SQL 2008 bekommen und eine mit Filestream.

Answer 1

Oft Skalierbarkeit und Leistung letztlich miteinander im Sinne verheiratet sind, dass sechs Monate ab jetzt Management kommt zurück und sagt „Funktion Y in Anwendung X unannehmbar langsam laufen, wie können wir es beschleunigen?“ Und allzu oft das die Antwort ist die Back-End-Lösung aufzurüsten. Und wenn es darum geht, Ziele zu aktualisieren zurück, die fast immer gehen zu weniger teuer als zu skalieren in Bezug auf die Hardware zu skalieren.

So lange Geschichte kurz, würde ich empfehlen, eine Middleware-Applikation erstellen, die speziell eingehende Anfragen vom Benutzer App behandelt und dann leitet sie an das entsprechende Ziel. Dies wird Ihr Front-End-Anwender-App aus der Back-End-Speicherlösung ausreichend abstrakt, so dass, wenn die Skalierbarkeit zu einem Problem wurde nicht nur das Middleware-App muß aktualisiert werden.

Answer 2

Das ist einfach. Schreiben Sie die Anwendung auf eine Schnittstelle, verwenden Sie eine Art von Fabrik-Mechanismus, die eine Schnittstelle zu liefern und implementieren diese Schnittstelle immer Sie wollen.

Wenn Sie mit Ihrer Schnittstelle zufrieden sind, dann ist die Anwendung (meistens) aus der Umsetzung isoliert, ob es gerade auf eine DB oder zu einer anderen Komponente spricht.

voraus ein wenig auf Interface-Design Denken aber Knochen dumm zu tun „es ist einfach, es funktioniert hier, es funktioniert jetzt“ Implementierungen bieten eine gute Balance von Zukunftssicherheit des Systems zwar nicht unbedingt über Engineering es.

Es ist einfach, Sie zu argumentieren, nicht einmal an dieser Stelle eine Schnittstelle benötigen, sondern nur eine einfache Klasse, die Sie instanziieren. Aber wenn Ihr Vertrag ist gut definiert (das heißt die Schnittstelle oder Klasse Signatur), ist es das, was Sie zum Schutz vor Veränderung (wie die Back-End-Implementierung redoing). Sie können die Klasse mit einer Schnittstelle später immer ersetzen, wenn Sie es für notwendig erachten.

Was Skalierbarkeit testen. Dann wissen Sie nicht nur, wenn Sie skalieren können müssen, aber vielleicht, wenn auch. „Funktioniert gut für 100 Benutzer, problematisch für 200, wenn wir 150 treffen könnten wir noch einen Blick auf das hintere Ende betrachten wollen nehmen, aber es ist jetzt gut.“

Das ist Due Diligence und eine verantwortliche Design Taktik, IMHO.

Answer 3

Ich bin mit gabriel1836. ein zusätzlicher Vorteil wäre jedoch sein, dass Sie für eine Zeit ein Hybridsystem einer Zeit lang laufen können, da Sie nicht mehr als 14 Millionen Dokumente von Ihrem proprietären System zu Ihnen nach Hause gewachsen System über Nacht konvertieren werden.

Auch ich würde Sie dringend ermutigen, außerhalb einer Datenbank, die Dokumente zu speichern. Bewahren Sie sie auf einem Dateisystem (lokal, SAN, NAS spielt es keine Rolle) und speichern Zeiger auf die Dokumente in der Datenbank.

Ich würde gerne etwas Dokumenten-Management-System wissen, dass Sie jetzt verwenden.

Auch nicht zu unterschätzen den Aufwand der Erfassung des Ersatzes (Scannen und Importieren) durch das proprietäre System zur Verfügung gestellt.