Documentum Performance Tuning mit dem High Volume Server
Jan 25, 2010 | by cmeier | 1 Comments

Der Documentum Content Server ist eine leistungsstarke und ausgereifte Plattform, die sich in zahlreichen Unternehmen bewährt hat. Jedoch gibt es Anwendungsfälle, bei denen die gewünschte Performance mit Hilfe des Content Servers nicht realisiert werden kann. EMCs Antwort auf dieses Problem heißt „High Volume Content Server“.

Eine Erweiterung, die spezielle Funktionalitäten für die performante Massenverarbeitung beinhaltet. Zu den Zielen des High Volume Servers gehören:

  • Die Minimierung von Hardware-Ressourcen
  • Die Steigerung der Objekt-Verarbeitung
  • Schnellerer Zugriff auf relevante Informationen in großen Repositories

Die Notwendigkeit für einen Einsatz des High Volume Servers sieht EMC in den folgenden drei Anwendungsszenarien:

  • High Volume Server als Stand-alone-Umgebung für eigenständige Individualanwendungen oder Transactional Content Management Anwendungen
  • Heterogene Content Server bei denen die High Volume Server Erweiterung nur für einen Teil oder von speziellen Clients der Anwendung genutzt bzw. vorausgesetzt wird
  • High Volume Server als Archivierungsplattform mit Compliance-Anforderungen, bei der effiziente Speicherung und Verarbeitungsgeschwindigkeit benötigt werden

Die Performance-Verbesserung des High Volume Servers wird mit Hilfe der Light Weight SysObjects, der Batch Verarbeitung, dem Scoping und der Partitionierung erreicht.

Light Weight SysObject
Die Light Weight SysObjects teilen dokumentenbezogene Metadaten in Vater- und Kind-Objekte auf. Das Vaterobjekt speichert allgemeine Daten, die für alle Kinder identisch sind, so dass in diesen nur noch spezifische Metadaten und gegebenenfalls Content gespeichert werden muss. Dadurch wird nicht nur die Performance beim Neuanlegen gesteigert, da weniger Operationen notwendig sind, sondern auch der Speicherplatz für ein Objekt verringert. Ein Nachteil der Light Weight SysObjects ist die eingeschränkte Funktionalität, die sich z.B. durch fehlende Unterstützung von virtuellen Dokumenten oder Workflows bemerkbar macht. Jedoch ist es möglich, das Light Weight Objekt in ein normales Objekt zu transformieren, wenn die eingeschränkten Funktionen benötigt werden.

1_lightweight

BatchProcessing
Für Anwendungen bei denen gleichzeitig eine große Anzahl ähnlicher Objekte im Repository erzeugt werden muss, bietet Batch Processing gegenüber der normalen Verarbeitung einen erheblichen Geschwindigkeitsvorteil. Die anzulegenden Objekte werden als Einheit ausgeführt, um wiederkehrende Verarbeitungsaufgaben zu eliminieren, da das Erzeugen von einzelnen Objekten eine ressourcenintensive Aufgabe ist. Alle anzulegenden Objekte werden über einen Aufruf vom Client zum Server angelegt, wie die nachfolgende Abbildung zeigt. Dadurch verringert sich der Netzwerkverkehr zwischen Client und Server. Des Weiteren wird eine schnellere Verarbeitung zwischen dem High Volume Server und der Datenbank erreicht. Die Batch-Verarbeitung wird durch das Interface „IDfBatchManager“ unterstützt, welches als eine optionale Erweiterung in der DFC Bibliothek implementiert ist.

2_batch

Scoping
Eine weitere Reduzierung von Ressourcen wird durch das Scoping erzielt. Prüfungen werden beim Abfragen oder Erstellen von Objekten nur für das erste Objekt durchgeführt, so dass für weitere Objekte, die innerhalb der aktiven Session erzeugt oder abgefragt werden, redundante Überprüfungen entfallen. Innerhalb der Session werden die benötigten Informationen der ersten Abfrage zwischengespeichert, und sind so für die nachfolgenden Abfragen nutzbar. Neben dem Batch Processing wurde auch das Scoping als optionale Erweiterung in der DFC Bibliothek implementiert. Die Abbildung zeigt, dass ab der zweiten Abfrage weniger Überprüfungen für das Anlegen eines Objekts notwendig sind und dies einen Geschwindigkeitsvorteil bringt.

3_scoping

Data Partitioning
Das Data Partitioning hilft, die Storagekosten zu minimieren und dabei die Zugriffsgeschwindigkeit auf relevante Daten zu erhöhen. Durch die Verteilung der Datenbanktabellen eines Repositories in verschiedene Partitionen können unterschiedliche Speichermedien eingesetzt werden. Die Verteilung der Objekte sollte sich an der Zugriffshäufigkeit orientieren, so dass die Speicherung von häufig zugegriffenen aktuellen Daten auf sehr schnellen Medien und von älteren Daten, die seltener abgefragt werden, auf langsameren Medien erfolgt.

Der Einsatz des Data Partitioning erfordert besondere Objekttypen, die ein zusätzliches Attribut für die Partitionseinteilung besitzen. Auf dem Server werden die Datenbanktabellen der Repository-Objekte in einzelne Partitionen aufgeteilt. Jede Partition besitzt einen vorher festgelegten Wertebereich, so dass der High Volume Server beim Speichern eines Objekts anhand des extra Attributs die richtige Partition auswählt. Des Weiteren wurde die Abfragesprache DQL erweitert, um die Vorteile des gezielten Abfragens einer Partition zu ermöglichen. Das Partitionieren des Repositories muss nicht nur von der Datenbank (Oracle oder Microsoft SQL Server), sondern auch vom eingesetzten Client mit Hilfe der DFC Bibliothek unterstützt werden.

Ein weiteres Highlight des Data Partitioning ist das Austauschen von Partitionen. Diese Funktion ermöglicht es, eine sehr große Anzahl von Light Weight Objekten ohne die Verwendung des Content Servers in eine vorher angelegte Datenbankpartition (Offline Partition) zu schreiben. Durch einen anschließenden Neustart des Content Servers wird die gesamte Offline Partition im Repository zur Verfügung gestellt. Die Vorteile vom Partitionsaustausch liegen in der schnellen Bereitstellung von großen Datenmengen sowie der entfallenen Beanspruchung des Content Servers beim Erstellen der Objekte.

4_partition

Fazit
Der High Volume Server bietet im Vergleich zum normalen Content Server einige sehr wertvolle Funktionen, die die Verarbeitungsgeschwindigkeit für große und spezielle Anwendungsfälle deutlich steigern. Darüber hinaus können durch den Einsatz von unterschiedlichen Speichermedien erhebliche Storagekosten eingespart und die Zugriffszeit auf relevante Daten reduziert werden. Jedoch unterstützen noch nicht alle Documentum Clients den vollen Funktionsumfang des High Volume Servers, so dass die Entwicklung von spezifischen Clients notwendig ist, um alle Vorteile zu nutzen. Dadurch ist zurzeit der Einsatz des High Volume Server auf einzelne Documentum Clients (My Documentum for Outlook und xCP – TaskSpace) sowie Eigenentwicklungen beschränkt.

Eine Antwort zu “Documentum Performance Tuning mit dem High Volume Server”

  1. […] Dieser Eintrag wurde auf Twitter von Dirk Bode, fme Group erwähnt. fme Group sagte: Documentum Performance Tuning mit dem High Volume Server: Der Documentum Content Server ist eine leistungsstarke u… http://bit.ly/8OyxQI […]