Open Source Dokumentenmanagement
Dokumentation

Durchsuchbare Dokumentation aufrufen | Zurück zur Dokumentationsübersicht

Navigation: Dokumentationen agorum core > agorum core sichern und wiederherstellen > Historie und Versionierung von Dokumenten > agorum core storage

Einführung in das Modul "agorum core storage"

Diese Dokumentation beschreibt die grundlegende Funktionsweise und Inhalte des Moduls agorum core storage.

Funktionsweise

Mit dem Modul binden Sie agorum core an externe Datenspeicher (etwa SSD-Festplatten) an, wodurch Dokumente auf unterschiedlichen Storage-Systemen gesichert werden. So speichern Sie große Mengen an Daten kosteneffizient und zeitsparend ab.

Definition des Begriffs „Storage“

Unter dem Begriff Storage verbirgt sich nicht wie üblicherweise verwendet ein lokales Dateisystem, wie es etwa auf einem Client / Rechner zur alltäglichen Speicherung von Dateien eingesetzt wird. Stattdessen lagern Sie mit dem Modul Content auf externe Datenspeicher (Storages) aus (etwa SSD-Festplatten). Dabei können Sie beliebig viele Storages einsetzen, um Datenspeicher zu verteilen.

Verfahren bei der Speicherung von Daten

Grundlegend speichert agorum core alle Daten in die Datenbank. Bei jeder Speicherung wird eine Datei in je 512 KB-Datenblöcke in der Datenbank unterteilt. So ergibt etwa eine 10 MB große Datei 20x 512 KB Datenblöcke. Durch dieses Verfahren können beliebig große Dateien in der Datenbank gespeichert werden.

Verwenden Sie das Modul agorum core storage, verbleiben nur Verweise auf diese Datenblöcke in der Datenbank, die eigentlichen Datenblöcke und deren Content und damit auch die deutlich größeren Datenmengen werden in ein separates Storage, dem externen Datenspeicher, ausgelagert. Damit bleibt Ihre eigentliche agorum core-Datenbank schlank und es besteht nicht die Gefahr, dass sie im Laufe der Zeit langsamer wird.

Hinweis: Von dieser Regelung ausgenommen sind etwa MetaDB-Einträge, Skripte und Libraries. Diese dürfen nicht ausgelagert werden, da agorum core diese Informationen beim Starten oder Ausführen von Funktionen benötigt und diese dann nicht in der Datenbank finden kann.

Gründe gegen große Datenbanken

Deduplizierung

Die Deduplizierung ist Bestandteil des Moduls. Mit ihrer Hilfe wird etwa ein identischer 512 KB Datenblock, der sich bereits im Storage befindet, nicht erneut im Storage abgelegt. Das System verweist nur auf diesen bereits existierenden Datenblock.

In der Standardeinstellung, d. h., wenn das Modul agorum core storage nicht verwendet wird, werden Dokumente entsprechend oft in der Datenbank gespeichert. Grundlage ist dabei die Historie / Versionierung eines Dokuments.


Beispiel
Für jede Änderung an einem Dokument, die durch einen Prozess oder händisch erfolgt (agorum core docform scannt ein Dokument, es wird ein Metadatum geändert, das Dokument wird umbenannt usw.), erzeugt das System einen Eintrag in der Historie. Wenn Sie das Modul agorum core storage nicht verwenden, wird dieses Dokument jedes Mal neu in der Datenbank abgespeichert, wenn ein solcher Eintrag in der Historie entsteht. Das verursacht schnell große Datenmengen. Diese ungewollte „Dopplung“ kann durch die Deduplizierung vermieden werden.

Hinweis: Damit Sie die Deduplizierung verwenden können, aktivieren Sie die Parameter VerificationEnabled sowie De-duplication.

Gründe für eine Deduplizierung

Asynchrone und synchrone Deduplizierung

Bei der Deduplizierung kommen zwei Verfahren zum Einsatz, zwischen denen Sie wählen können:


Asynchrone Deduplizierung

Die asynchrone Deduplizierung ist das empfehlenswerte Vorgehen. Das System prüft hierbei dauerhaft alle Blöcke auf Vorhandensein und markiert alle zu löschenden Blöcke. Der Effekt der Deduplizierung tritt erst nach einiger Zeit ein. Ein CronJob entfernt alle markierten Blöcke und ist im Standard auf einen siebentägigen Versatz eingestellt. Die gedoppelten Daten werden also nicht direkt entfernt.

Synchrone Deduplizierung

Die synchrone Deduplizierung ist nicht empfehlenswert, da diese beim Schreiben der neuen Blöcke langsamer arbeitet. Das System prüft hierbei zwar ebenfalls alle Blöcke auf Vorhandensein, allerdings löscht es im Vergleich zur synchronen Deduplizierung die Blöcke direkt. Der Effekt der Deduplizierung tritt sofort ein. Dadurch werden Ressourcen blockiert, weil zwei Vorgänge auf einmal durchgeführt werden müssen.

Unterschied zwischen Filesystem-Storage und Container-Storage

Das Modul agorum core storage ermöglicht es Ihnen, zwischen zwei Storage-Systemen zu entscheiden:

Es ist auch möglich, von einem Filesystem-Storage auf ein Container-Storage zu wechseln und umgekehrt (siehe Vom Container-Storage auf ein Filesystem-Storage wechseln).

Filesystem-Storage

Das Filesystem-Storage wird üblicherweise verwendet. Dabei wird an beliebiger Stelle eine HDD- oder SSD-Festplatte eingesetzt, auf denen sich eine Vielzahl an Ordnern und Dateien mit Zahlen- und Buchstabenkombinationen befinden, mit denen ein herkömmlicher Benutzer nichts anfangen kann. D. h. es werden hier keine gewöhnlichen PDF-Dokumente o. Ä. dargestellt. Es handelt es sich hierbei um den eigentlichen Content der Daten. Wenn das System diesen Content ausgelagert, wird der Content in kleine Blöcke unterteilt. Diese Funktionsweise wurde bereits eingangs erwähnt. Die Deduplizierung erfolgt auf der Blockebene, nicht auf der Dokumentebene, d. h. nur der Index muss auf dem schnellen System liegen. Der Inhalt kann auch wieder auf eine langsamere Platte ausgelagert werden. Zudem werden Hashwerte zur Deduplizierung benötigt.

Container-Storage

Das Container-Storage wird alternativ verwendet, kommt jedoch selten zum Einsatz, weil es langsamer als ein Filesystem-Storage ist. Die Daten werden ähnlich wie in einer Datenbank in Containern gespeichert, es werden viele Datenblöcke in einer Datei (Container) zusammengefasst. Für die Datensicherung müssen Daten im Volltextindex bzw. Solr, Daten im Storage und Daten in der Datenbank zueinanderpassen. Bei der herkömmlichen Datensicherung von geänderten Dateien wird das nur erreicht, indem das agorum core-System in der Zeit der Sicherung gestoppt wird. Alternativ erfüllen Sie diese Anforderung durch eine Snapshotsicherung, bei der für ein paar Sekunden die Datenbank gestoppt wird. Ohne Snapshotsicherung ist die Datensicherung bei riesigen Datenmengen nicht mehr durchführbar. Die Sicherung dauert zu lange, als dass Sie das System abschalten könnten (üblicherweise läuft ein solch zentrales System wie agorum core rund um die Uhr).

Konsistenz der ausgelagerten Daten prüfen

Das Modul ermöglicht es, den ausgelagerten Content im agorum core storage gegen die Datenbank prüfen zu lassen, indem das System für einen Contentblock den Hashwert berechnet. Dieser wird mit dem in der Datenbank abgelegt Hashwert dieses Datenblocks verglichen. Stimmt der Hashwert nicht überein, wird eine Fehlermeldung geschrieben.

Durch das parallele Laufen mehrerer Threads ist es möglich, dass die Deduplizierung selten nicht sofort erfolgt. Das geschieht, wenn mehrere Threads denselben Content schreiben, aber in diesem Zustand nichts voneinander wissen. Die hier beschriebene Funktion korrigiert die Deduplizierung auch im Nachhinein für die Blöcke, die bisher nicht dedupliziert waren.

Bei agorum core-Systemen, die älter als Version 8.1.3 sind und noch ohne die Deduplizierung auskamen, wurde der Hashwert nicht in die Datenbank geschrieben. Dieses Modul schreibt den Hashwert beim ersten Durchlauf in die Datenbank und führt die Prüfung im zweiten durch.

Vorraussetzungen

Geprüfte Blöcke und Daten einsehen

Wie viele Blöcke und Daten das System geprüft und verifiziert hat, sehen Sie im agorum core support tool:

  1. Öffnen Sie links in der Seitenleiste Weitere Apps und dann Support tool.
  2. Wählen Sie links im Menü Storage > Sub Statistics > Storage verifier.

    Ergebnis: Im Abschnitt Measurements sehen Sie die aktuellen Prüfdaten.
Prüfdaten im agorum core support tool einsehen