DE102008024809B3

DE102008024809B3 - Verfahren zur Speicherung einer Mehrzahl von Revisionen von baumstrukturartig verknüpften Datenfamilienteilen

Info

Publication number: DE102008024809B3
Application number: DE102008024809A
Authority: DE
Inventors: Marc Ives Maria Kramis
Original assignee: Universitaet Konstanz
Current assignee: Universitaet Konstanz
Priority date: 2008-05-23
Filing date: 2008-05-23
Publication date: 2009-11-19
Anticipated expiration: 2028-05-24
Also published as: WO2009141162A1; WO2009141161A1

Abstract

Ein Verfahren zur Speicherung einer Mehrzahl von Revisionen (Rr) von baumstrukturartig verknüpften Datenfamilienteilen, die jeweils eine Anzahl von miteinander baumartig verknüpfter Datenseiten (Pr,p) mit einer zentralen Eltern-Datenseite (PPr,0) und von dieser ausgehenden Kinder-Datenseiten (PPr,x) haben, wird beschrieben. Für jede Revision (Rr) wird ein Haupt-Referenzzeiger (RRr) auf die Eltern-Datenseite (PPr,0) der jeweiligen Datenseite (Pr) in einer separat abgespeicherten Liste (NDLr,p) bereitgestellt. Die Datenseiten (Pr) haben mindestens einen Seiten-Referenzzeiger (PRr,p) auf logisch unmittelbar nachfolgend verknüpfte Kinder-Datenseiten (PPr,x). Knotenänderungsinformationen über Änderungen von eine Referenz auf logisch unmittelbar nachfolgend verknüpfte Kinder-Datenseiten (PPr,x) definierende Knoten der Struktur baumartig verknüpfter Datenfamilienteile werden für jede Revision (Rr) abgespeichert.

Description

Die Erfindung betrifft ein Verfahren zur Speicherung einer Mehrzahl von Revisionen von baumstrukturartig verknüpften Datenfamilienteilen, die jeweils eine Anzahl von miteinander baumartig verknüpfter Datenseiten mit einer zentralen Eltern-Datenseite und von dieser ausgehenden Kinder-Datenseiten haben, wobei für jede Revision ein Haupt-Referenzzeiger auf die Eltern-Datenseite der jeweiligen Datenseite in einer separat abgespeicherten Liste bereitgestellt wird und die Datenseiten mindestens einen Seiten-Referenzzeiger auf logisch unmittelbar nachfolgend verknüpfte Kinder-Datenseiten haben.
Informationen können digital hierarchisch strukturiert mit Hilfe des so genannten Extensible Mark-Up-Language XML abgespeichert werden. XML ist eine Aufzeichnungssprache zur Darstellung hierarchisch strukturierter Daten in Form von Textdateien. Das XML-Format wird insbesondere für den Austausch von Daten zwischen unterschiedlichen Computersystemen eingesetzt. Ein XML-Dokument besteht aus Elementen, Attributen, ihren Wertzuweisungen und dem Inhalt der Elemente, der aus Text oder aus untergeordneten Elementen bestehen kann. Die untergeordneten Elemente können ihrerseits wieder Attribute mit Wertzuweisungen und Inhalt haben. In einem XML-Dokument können Elemente mit und ohne Attribute vorkommen. Weiterhin können Elemente vorhanden sein, die ihrerseits viele andere Elemente enthalten. Weiterhin können Elemente lediglich Text oder sogar keinen Inhalt haben. Die Elemente, Attribute und Wertzuweisungen bilden eine Baumstruktur, die einer Verzeichnis- und Dateistruktur herkömmlicher Computersysteme ähnelt. Eine XML-Datei wird von einem so genannten XML-Paser abgearbeitet, indem der Hierarchie gefolgt wird, die sich durch die Baumstruktur der Daten ergibt. Jedes Elemente, jedes Attribut, jede Wertzuweisung an ein Attribut und jeder Zeicheninhalt eines Elements ist dabei ein eigener Bestandteil des Baums, der einzeln adressierbar ist. Diese Bestandteile werden auch als Knoten bezeichnet. Jedes XML-Dokument beginnt mit einem Wurzelknoten, der den Ursprung der Daten bildet. Der Wurzelknoten verweist auf ein äußerstes, den gesamten übrigen Inhalt der XML-Datei umfassendes Element, das heißt den obersten Knoten. An einen solchen Knoten schließen sich ein oder mehrere Kindknoten an, aus deren Sicht der übergeordnete Knoten einen Elternknoten bildet.
Mit einem solchen XML-Dokument, bei dem Eltern- und Kinderdatenseiten miteinander hierarchisch verbunden sind, lassen sich systemunabhängig Daten verwalten und insbesondere Revisionen von Datensammlungen so abspeichern, dass die Revisionshistorie nachvollziehbar ist. Dies ist insbesondere dann hilfreich, wenn eine Mehrzahl von Bearbeitern an demselben Objekt arbeiten, wie bspw. der Erstellung von Textdokumenten.
Es existieren eine Vielzahl von nativen XML-Datenbanken, die eine Enkodierung zur internen Repräsentation von XML-Daten als ungereihter, geordneter Baum mit der Randbedingung repräsentiert, dass die Ordnung der Kinder jedes Knotens stabil ist. Der enkodierte Baum wird in einem Speichersystem abgespeichert. Die nativen XML-Datenbanken machen den abgespeicherten Baum über ein Interface zugänglich.
Es existieren vier Hauptklassen zur Enkodierung. Das Enkodieren mit einem Schlüssel fester Größe weist jedem Knoten einen einzigartigen, nicht flüchtigen Schlüssel fester Größe zu. Ein Vergleich von zwei Schlüsseln reflektiert nicht notwendiger Wei se die globale Reihenfolge der zwei aufeinander bezogenen Knoten. Jeder Knoten speichert Schlüssel seiner unmittelbaren Nachbarknoten. Aktualisierungen sind nicht skaliert, wenn ein Knoten eine große Anzahl von Kindern enthält. Das Enkodieren mit einem Schlüssel variabler Größe weist jedem Knoten einen einzigartigen, nicht flüchtigen Schlüssel variabler Größe zu. Einen Vergleich von zwei Schlüsseln reflektiert immer die globale Ordnung der zwei aufeinander bezogenen Knoten. In Abhängigkeit einer Einfügeposition kann die Größe des Schlüssels unbegrenzt ansteigen. Aktualisierungen sind für ständige Einfügungen in der angrenzenden Nachbarschaft eines einzelnen Knotens nicht skaliert.
Die Positionenkodierung weist jedem Knoten einen einzigartigen, flüchtigen Schlüssel fester Größe zu. Ein Vergleich von zwei Schlüsseln reflektiert immer die globale Ordnung der zwei aufeinander bezogenen Knoten. Der Schlüssel eines Knotens entspricht der aktuellen Position des Knotens, während Aktualisierungen die Position aller Knoten ändern, die den eingefügten oder gelöschten Knoten folgen. Aktualisierungen sind nicht skaliert, falls zusätzliche Indizes, wie ein Volltextindex involviert sind. Die vierte Art der Kodierung ist ein indexbasiertes Verfahren, bei dem eine oder mehrere Indizes für jeden Knoten vorhanden sind, um typische Abfragen zu beschleunigen. Hierzu muss das Original XML-Dokument für eine korrekte Rekonstruktion verfügbar gehalten werden. Aktualisierungen sind nicht skaliert, so dass das Original XML-Dokument und alle Knoten nach dem Einfügen oder Löschen von Knoten aktualisiert werden muss. Weiterhin existieren zwei grundlegenden Speichersystemklassen. Die erste Speichersystemklasse überschreibt existierende Daten bei der Ausführung von gegenwärtigen Aktualisierungen. Hierzu wird eine Baumkopie oder ein Feld üblicherweise teilweise oder vollständig im Speicher gehalten und während der Aktualisierung auf das Speichermedium zurückgeschrieben. Alte Daten werden teilweise oder vollständig überschrieben oder gelöscht.
Die zweite Speicherklasse führt Aktualisierungen mit Kopien beim Schreibvorgang ohne ein Überschreiben alter Daten aus. Hierbei wird ein Index sowie die Revision der Daten bereitgehalten. Ein neuer Index und neue Daten werden lediglich an die alten Informationen angehängt. Die Indexpunkte auf Daten entsprechen einer Revision und können damit entweder auf einen vollen Dateninhalt oder auf eine Sequenz von inkremmentalen Änderungen, das heißt auf den Unterschied zwischen den Dateninhalten zweier aufeinander folgende Revisionen zeigen, die zur Rekonstruktion der vollen Dateninhalte genutzt werden können.
Weiterhin existieren vier grundlegende Schnittstellenklassen, nämlich eine Schnittstelle zur Anwendungsprogrammierung (API = Application Programming Interface), zur integrierten Interaktion (Embedded Interaction) einer anwenderbezogenen Schnittstelle API für alleinstehende Interaktion (Stand Alone Interaction), eine anwenderbezogenen Schnittstelle API zur Web-basierten Interaktion sowie ein Text und/oder grafisches Nutzerinterface zur Mensch-Maschine-Interaktion.
C. Grün, A. Holupirek, M. Kramis, M. H. Scholl, M. Waldvogel: ”Pushing XPath Accelerator to its Limits”, in Proceedings of the First International Workshop and Performance and Evaluation of Data Management Systems, June 30, 2006 Chicago, Illinois, USA, beschreibt die Struktur von XML-Daten und Konzepte zur Enkodierung. Durch ein Set von Index-Tupel und Index-Blockstrukturen kann die Aktualisierungszeit reduziert werden. Die Dateistruktur wird mit einer Namensliste, einer Knotenliste und einer Werteliste verwaltet.
US 6,938,075 B1 offenbart ein Software-Verteilungssystem, bei dem zur Minimierung der bei der Softwareübertragung über ein Netzwerk genutzten Bandbreite nur die Datenpakete, die durch einen Knoten eines baumartig strukturierten Netzwerkes erforderlich sind, nur über die übergeordneten Verbindungen geschickt werden.
US 7,111,233 B1 offenbart ein Verfahren und ein System zur Modifikation von Programmapplikationen, wobei Daten im erweiterten Auszeichen- und Sprachenformat aus einer auf einem Computersystem laufenden Anwendung ausgegeben werden. Mit Hilfe einer Kontexttabelle, mit der ein Modell von Schreibeoperationen eine Altcomputeranwendung auf ein erweiterbares Auszeichen- und Sprachenschema abgebildet wird, wird das Verhältnis eines Schemaelementes der Ausgabedaten innerhalb des erweiterbaren Auszeichen- und Sprachenschemas und ein gegenwärtiger Kontext bestimmt. Weiterhin werden erweiterbare Auszeichnungssprachen-Tax für die Schemaelemente bis hinunter zum Schemaelement der Ausgabedaten geöffnet, um letztendlich die Daten und die geeigneten erweiterbaren Auszeichnungssprachen-Tax von einer Schreibervorrichtung in erweiterbarem Auszeichnungssprachenformat auszugeben. Die direkte Erzeugung von XML formatierten Daten von einem Altcomputersystem reduziert Reibungen in Informationsnetzwerken durch eine Vereinfachung des Informationstransfers.
Das der Erfindung zugrunde liegende Problem liegt in der effizienten Speicherung und Suche von Revisionen baumartig verknüpfter Datenfamilienteile, insbesondere unter dem Gesichtspunkt, dass die Größe und Struktur der verknüpften Datenfamilienteile von Revision zu Revision nicht vorhersagbar unterschiedlich ist.
Die Aufgabe wird mit dem Verfahren der eingangs genannten Art erfindungsgemäß gelöst durch Abspeichern von Knotenänderungsinformationen für jede Revision über Änderungen von eine Referenz auf logisch unmittelbar nachfolgend verknüpfte KinderDatenseiten definierende Knoten der Struktur baumartig verknüpfter Datenfamilienteile.
Es wird somit vorgeschlagen, für jede Datenseite einer Revision Informationen über die Änderungen bezogen auf die vorhergehende Revision in einer separaten Knotenliste als Knotenänderungsinformation abzuspeichern. Durch das Abspeichern der Knotenänderungsinformation für jede Revision wird eine weitere suchbare- und aus- wertbare Liste bereitgestellt, aus der unmittelbar die Änderungen der Knoten einer Datenseite erkennbar sind. Dort wird die Revision bereits anhand der Versionisierung der Baumsstruktur erkennbar, die über die abgespeicherten Knotenänderungsinformationen als Informationsfeld zugänglich ist. Dies hat den Vorteil, dass die Änderungsanweisung nicht erst umständlich über die Haupt- und Seitenreferenzzeiger ausgehend von einem Wurzelknoten ausgewertet werden müssen. Nicht persistent gemachte Seiten in einem Arbeitsspeicher können so aus persistenten Seitenteilen hergeleitet werden.
Die Knotenänderungsinformationen können das Hinzufügen neuer Knoten, das Löschen von Knoten und/oder die Änderung von Knoten kennzeichnen. Durch die separate Abspeicherung von Knotenänderungsinformationen in eine zusätzliche, die Änderung der Knoten einer Datenseite enthaltene Liste wird somit vermerkt, ob im Vergleich zur vorhergehenden Revision ein zusätzlicher Knoten hinzugefügt, gelöscht oder geändert worden ist.
Die Kinder-Datenseiten können die Änderung der entsprechenden Kinder-Datenseite an einer unmittelbar vorhergehenden Revision in Form von Differenzdaten enthalten. Dies hat den Vorteil, dass nicht der vollständige Inhalt der Datenseite abgespeichert werden muss, sondern lediglich die nicht binäre Änderungsinformationen, was zu einem reduzierten Speicherbedarf führt und keine aufwändigen Berechnungen erfordert.
Die Datenseiten können aber auch den vollständigen Dateninhalt enthalten, der in der jeweiligen Revision optional modifiziert wurde.
In einer bevorzugten Ausführungsform sind die Hauptreferenzzeiger oder Kopien der Hauptreferenzzeiger auf einem weiteren Datenspeichermedium separat von den referenzierten Datenseiten abgelegt. Dies hat nicht nur den Vorteil der erhöhten Datensicherheit durch Redundanz, sondern ermöglicht auch einen schnelleren Datenzugriff, da die Suche in den Hauptreferenzzeigern auf dem separaten Datenspeichermedium parallel zum Auslesen oder Schreiben von Datenseiten erfolgen kann.
Denkbar ist aber auch, dass die Hauptreferenzzeiger oder Kopien davon in Sektoren eines Datenspeichermediums getrennt von den Sektoren desselben Datenspeichermediums abgelegt sind, in denen die referenzierten Datensätze gespeichert sind. Durch die Aufteilung in Sektoren wird sichergestellt, dass die baumartigen Strukturen der Daten zusammenhängend hintereinander abgelegt werden können, wie auch die Hauptreferenzzeiger, ohne dass die Speicherorte verwürftelt werden.
Weiterhin ist es vorteilhaft, wenn die Speicherung der Revision von Datenfamilien durch Verschlüsselung abgesichert wird. Durch Verschlüsselung sollte die Performance allerdings nicht wesentlich eingeschränkt werden. Es wird daher vorgeschlagen, ein Kryptographieverfahren basierend auf einem kodierten Hash-Nachrichten-Authentifizierungscode anzusetzen, bei dem eine kryptographische Hash-Funktion in Kombination mit einem geheimen Schlüssel eingesetzt wird. Zusätzlich wird eine symmetrische Verschlüsselung eingesetzt. Hierzu wird einer geheimer Masterschlüssel definiert und unabhängig von dem Masterschlüssel eine Zusatzkennung generiert. Diese Generierung der Zusatzkennung, die auch Salt genannt wird, wird auch als Salting bezeichnet. Aus dem Masterschlüssel und der Zusatzkennung wird ein Schlüssel abgeleitet. Dies wird auch als Stretching bezeichnet. Für jede Datenseite wird dann ein jeweils einzigartiger Ad-Hoc-Schlüssel und ein Zähler aus Ergebnissen der Ver-/Entschlüsselungsalgorhithmen übergeordneter Datenseite zur Verschlüsselung, Entschlüsselung und Authentifizierung mindestens der zugeordneten Hauptreferenzzeiger, Datenseiten und mindestens eines Kopfteils für die Gesamtheit der Revision der gespeicherten Datenfamilien abgeleitet.
Das Verschlüsselungsverfahren kann beispielsweise Gebrauch machen von dem standardisierten Advanced-Encryption-Standard, z. B. CTR-AES-256 und dem Hash-Authentifizierungsverfahren, wie z. B. HMAC-SHA-256. Das Auslesen der gespeicherten Revisionen von Datenseiten kann vorzugsweise erfolgen durch die Schritte:

a) Verifizieren der Übereinstimmung gespeicherter Kopien eines Kopfteils für die Gesamtheit der Revision gespeicherter Datenfamilien;
b) Verifizieren der Übereinstimmung einer in einem separaten Datenspeichermedium oder auf einem separaten Sektor eines Datenspeichermediums abgeleg ten Kopie eines Hauptreferenzzeigers für die aktuelle Revision mit einem Hauptreferenzzeiger der aktuellen Revision, die auf einem Sektor des Datenspeichermediums zusammen mit den zugehörigen Datenseiten der Revision abgelegt sind,
c) Zugreifen auf Datenseiten gewünschter Revisionen über im Hauptzeiger für die entsprechende Revision und den Seitenreferenzzeigern enthaltenen Zeigern und
d) Auswerten von Knotenänderungsinformationen für jede Revision über Änderungen von einer Referenz auf logisch unmittelbar nachfolgend verknüpfte Kinder-Datenseiten definierende Knoten.

Das Zugreifen auf eine gewünschte Revision kann mittels des binären Suchalgorithmus über die Liste der Hauptreferenzzeiger erfolgen, wobei gleichermaßen an Hand der Revisionsnummer und/oder des im Hauptreferenzzeiger gespeicherten Zeitstempels gesucht werden kann.
Die Erfindung wird nachfolgend anhand von Ausführungsbeispielen mit den beigefügten Zeichnungen näher erläutert. Es zeigen:
1 – Speicherschema zur Speicherung einer Mehrzahl von Revisionen baumstrukturartig verknüpfter Datenfamilien mit zwei separaten Datenspeichern;
2 – Speicherschema der Speicherung einer Mehrzahl von Revisionen von baumstrukturartig verknüpfter Datenfamilien unter Nutzung von zwei Sektoren eines einzigen Datenspeichers;
3 – beispielhafte Darstellung des logischen und physischen Seiten- und Seitenteilbaums für vier Revisionen;
4 – Darstellung des Zustandsdiagramms eines Verfahrens zur Speicherung einer Mehrzahl von Revisionen von baumstrukturartig verknüpfter Datenfamilien;
5 – Flussdiagramm des Verfahrens zur Serialisierung einer im Speicher abgelegten Datenseite auf einen Festspeicher.
6 – beispielhafte Darstellung einer Art zur Abspeicherung von Knoten.
1 lässt die Speicheraufteilung unter Verwendung von zwei logischen Datenspeichern LD₁ und LD₂ erkennen. Jeder Datenspeicher LD_d mit d = 0, 1, ... n besteht aus einem Feld von Sektoren S_d,s mit der maximalen Anzahl von max(s) von Sektoren. Jeder Sektor kann beispielsweise 512 Byte breit sein. Die Datenspeicher LD_d unterstützen einen zufälligen Schreib- und Lesezugriff auf jeden Sektor S_d,i, wobei die Datenspeicher für Zufallslesen (random-read) und sequentiellen Schreibaktivitäten optimiert sein sollte. Der benötigte Speicherplatz auf den Datenspeichern LD_d wächst ständig zu jeder Zeit durch Hinzufügen weiterer Sektoren, wobei die Anzahl von Schreibzugriffen auf jeden Sektor S_d,i begrenzt sein kann.
Es ist erkennbar, dass alle Daten und Metadaten auf dem primären logischen Datenspeicher LD₁ abgelegt werden. In dem in der 1 dargestellten Ausführungsbeispiel werden die Metadaten zudem auf dem zweiten logischen Datenspeicher LD₂ abgelegt, um die Speicherung und das Auslesen von Revisionen sowie die Suche von Revisionen zu beschleunigen. Durch die redundante Abspeicherung in dem zweiten Datenspeicher LD₂ kann der Dateninhalt des zweiten Datenspeichers LD₂ jederzeit aus dem ersten Datenspeicher LD₁ rekonstruiert und auf Konsistenz geprüft werden. Inkrementale Backups des Dateninhalts auf dem ersten und/oder zweiten Datenspeicher LD₁ und/oder LD₂ können synchron oder asynchron auf einem oder mehreren anderen weiteren Datenspeichern LD_d zur Datensicherung abgelegt werden. Als Metadaten sind zunächst sogenannte Kopfdaten H_h (header) vorgesehen, die für das Salting eine Zusatzkennung SLT_h (salt) von beispielsweise 32 Byte, eine Konfiguration CONF_h von beispielsweise 448 Byte und ein Token HT_h von 32 Byte enthalten, der zur Authentifizierung der Konfiguration CONF_h genutzt wird. Der Token HT_h entspricht dem Authentifizierungsalgorithmus HMAC-SHA-256_k (CONF_h). Der Algorithmus ist aus dem Secure-Hash-Standard: Federal Information Processing Standards Publication 180-2, National Institute of Standards and Technology, August 2002, aus dem Advanced Encryption Standard (AES): Federal Information Processing Standards Publication 197, National Institute of Standards and Technology, November 2001 und aus „The Keyed Hash-Message Authentication code (HMAC): Federal Information Processing Standards Publication 198, National Institute of Standards and Technology, March 2002, hinreichend bekannt.
Die Zusatzkennungen SLT_h, d. h. die ersten 32 Byte des Headers H_h werden nicht verschlüsselt. H_h wird zweifach auf dem ersten Datenspeicher LD₁ als H₀ und H₁ und zweifach auf dem zweiten Datenspeicher LD₂ als H₂ und H₃ abgelegt.
Als Metadaten werden weiterhin Revisions-Referenzen RR_r abgespeichert, die eine Seitenteilreferenz PPR_r,0 (z. B. 32 Byte) und das Token RRT_r (z. B. 32 Byte) enthält, das zur Authentifizierung der Seitenteilreferenz PPR_r,0 verwendet wird. Das Token RRT_r entspricht dem Authentifizierungsalgorithmus HMAC-SHA-256_k (PPR_r,0). Weiter enthalten die Revisions-Referenzen (RR_r) Angaben über den Autor sowie den Zeitpunkt der Erstellung der Revision R_r.
Um ausgehend von der aktuellsten Revision R_max(r) die vorhergehende Revisionsreferenz RR_max(r)-1 auf dem zweiten Datenspeicher LD₂ aufzufinden, wird eine binäre Suche auf den Sektoren S_2,2, ... S_2,max(s)-1 durchgeführt. Jedes Mal wird der Median des Sektors S_2,s ausgewählt, da angenommen wird, dass dieser einige Seitenteilreferenzen PPR_r,p bei einem Byte-offset von Null enthält. Falls das Token RRT_r gleich HMAC-SHA-256_k (PPR_r,0) ist, wird die Suche in die Richtung nach rechts fortgeführt und andernfalls in die Richtung nach links. Falls dort einige Revisionsreferenzen RR_max(r)-1 auf die Revision R_max(r)-1 vorhanden sind, wird die binäre Suche diese schließlich selektieren.
Falls der zweite Datenspeicher LD₂ nicht verfügbar ist, wird wiederum eine binäre Suche mit dem ersten Datenspeicher LD₁ wie vorstehend beschrieben ausgeführt. Falls der Median keine Revisionsreferenz RR_r,p auf eine Revision bei einem Byte-Offset von Null in einem Sektor S_s,1 zurückgibt, wird die Suche in Richtung nach rechts und links wie folgt fortgeführt. Die Revisionsreferenz RR_r,b wird in den Sektoren S_1,m+kj-1, ..., S_1,m+kj ausgehend von k_o = 1 gestartet. Falls sie nicht gefunden wird, erfolgt eine Anpassung von kj = –2·k_j-1, bis k_j eine konfigurierbare Grenze erreicht. Anschließend wird wie oben beschrieben verfahren.
Aus logischer Sicht besteht eine im ersten Datenspeicher LD₁ abgelegte Revision R_r aus einem Baum von Datenseiten. Die Datenseiten sind beginnend mit der Wurzel-Datenseite P_r,0 aufgezählt. Anfänglich beinhaltet die Revision R_r alle Datenseiten von der vorhergehenden Revision R_r-1. Nachfolgende Änderungen werden nur auf Kopien der Datenseiten vorgenommen und nicht bei den Originalen. Die Kopien sind nur für die Revision R_r sichtbar und in rückwärtiger Ordnung als Datenseitenteile PP_r,0 abgespeichert. Falls die gesamte Datenseite gespeichert wird, ist die Kopie des Seitenteils als Seiten-Snapshot PS_r,p bezeichnet. Falls nur eine Änderung zur letzten Revision gespeichert wird, ist dies als Seitenänderung PD_r,p, d. h. als nicht binäre Differenz oder Delta bezeichnet.
Aus 1 ist erkennbar, dass für jede Revision R_r eine Datenseitenreferenz RR_r vorgesehen ist, die die Datenseite P_r,0 gleich PP_r,0 referenziert, die ein Seiten-Snapshot sein muss. Alle anderen Datenseiten werden durch eine Seitenreferenz PR_(r, p) referenziert, die entweder eine einzelne Seiten-Snapshot PS_r,p oder eine Sequenz von Seitenänderungen PD_r,p referenziert, wobei die Seitenänderungen auf einen anfänglichen Datenseiten-Snapshot PS_r,p angewandt werden, um eine Datenseite PP_r,p abzuleiten. Der Seitenteilzähler PPC_r,p bezeichnet die Anzahl der Seitenänderungen, die auf die anfängliche Seiten-Snapshots anzuwenden sind. Jede Seite wird dabei an eine Revision r und eine Seitennummer p gebunden, die die Seite eindeutig von allen anderen Seiten unterscheidet. Ein Seitenteil erhält somit über alle Revisionen dieselbe Seitennummer. Jede Seitenteilreferenz in einer Seitenreferenz PR_(r, p) ist mit der Revisionsnummer, während dieser dieses Seitenteil erstellt wurde, assoziiert. Eine Seitenreferenz mit dem Seitenzähler PPC_r,p gleich Null kennzeichnet eine gelöschte Seitenreferenz.
Eine nicht persistent gemachte Seite P_r,p enthält zwei Felder, das Seitenreferenzfeld PRA_r,p sowie das Knotenfeld NDA_r,p. Beide Felder sind das Ergebnis aller Änderungen aus allen Seitenteilen, die auf die Seite P_r,p bezogen sind. Die Größe der beiden Felder ist fest oder für jede Seite entsprechend ihrer entsprechenden Position in dem Seitenbaum definiert. Die maximale Größe der beiden Felder ist auf beispielsweise 256 limitiert. Jeder Eintrag in eines der Felder ist durch seine absolute Position n markiert. Ist n negativ, so bedeutet das, dass der Eintrag in einer früheren Revision geändert wurde. Der Eintrag θ ist nicht verwendet. Das erste Feld, d. h., das Seitenreferenzfeld PRA_r,p speichert die n-te Seitenreferenzen PR_rp', ..., PR_rp*, die auf die Kinder-Datenseiten P_r,p' ..., P_r,p* zeigen. Das zweite Feld, d. h. das Knotenfeld NDA_r,p speichert Knoten ND_p,n
Ein Knoten ND_p,n besteht aus einer z. B. ein Byte großen Position im Knotenfeld NDA_r,p einem Knotentyp von z. B. einem Byte und einer Nutzlast variabler Größe. Der Knotentyp kleiner 0 kennzeichnet einen gelöschten Knoten und enthält keine Nutzlast. Daher sind beispielsweise 127 verschiedene Knotenkinder verfügbar.
Ein Seitenteil PP_r,p ist entweder ein Seiten-Snapshot PS_r,p oder eine Seitenänderung PD_r,p. Ein Seiten-Snapshot PS_r,p speichert das Ergebnis aller vergangenen Änderungen sowie der Änderungen während der Revision R_r. Die Knotenänderung PD_r,p enthält lediglich die während der Revision R_r vorgenommenen Änderungen.
Das persistent gemachte Seitenteil PP_r,p enthält zwei Listen variabler Größe, die die an der Datenseite P_r,p während der Revision R_r vorgenommenen Änderungen reflektieren. Jede Liste enthält eingangs die Listengröße von einem Byte. Die maximale Größe beider Listen ist beispielsweise auf 256 begrenzt. Die erste Liste, die sogenannte Seitenreferenzliste PRL_r,p speichert Änderungen an jeglicher Seitenreferenz PR_r,p' ..., PR_r,p*, die auf die Kinderseiten P_r,p' ..., P_r,p* zeigen, wobei p < p' < ... < p* ist. Die zweite Liste, die sogenannte Knotenliste NDL_r,p speichert Änderungen an jeden Knoten ND_r,p,n. Falls das Seitenteil PP_r,p ein Seiten-Snapshot PS_r,p ist, speichert die Knotenliste NDL_r,p auch den aktuellen Zustand vom Knoten, falls dieser nicht während der Revision R_r modifiziert wurde.
Erkennbar ist aus 1, dass die Referenzen RR_r auf die Revisionen gefolgt von den Headern H₂ und H₃ hintereinander mit der ersten Referenz RR₀ auf die erste Revision R₀ abgespeichert werden.
In dem ersten Datenspeicher LD₁ werden die Revisionen R₀, R₁, ..., R_max(r) ebenfalls hintereinander unter Ausnutzung eines oder mehrerer Sektoren S_d,s abgelegt. Dabei werden die Daten einer Referenz RR_r in den genutzten Sektoren jedoch rückwärts abgelegt, wobei an dem Ende des letzten Sektors zunächst die Referenz RR_r auf die jeweilige Revision R_r abgelegt wird. Die Seitenteile PP_r,p der Revision R_r werden beginnend vom Anfang des ersten Sektors S_d,s der Revision R_r mit der letzten Kinder-Datenseite, d. h. dem Datenseitenteil PP_r,x bis zum Wurzel-Datenteil PP_r,0 abgelegt, so dass die Sequenz der Datenteile PP_r,p mit dem Wurzel-Datenteil PP_r,0 endet.
2 lässt eine andere Ausführungsform für die Speicherung einer Mehrzahl von Revisionen R_r von baumstrukturartig verknüpften Datenfamilien unter Verwendung eines einzigen logischen Speichermediums LD₀ erkennen. Die auf die Seitenteile verweisenden Kopien der Revisionsreferenzen RR_r auf die Revisionen R_r sowie die Kopien H₂ und H₃ der Header H₀ und H₁ werden in Sektoren S_0,max(s)-i getrennt von den Sektoren S_0,i für die Revisionen R_r abgelegt.
Während der Datenspeicherbereich für die Header H₀, H₁ und die Revisionen R_r sequentiell beginnend von einem ersten Sektor S_0,0 hintereinander in Vorwärts-Reihenfolge abgelegt werden, erfolgt die redundante Speicherung der Metadaten in Rückwärts-Richtung beginnend mit den Headern H₂ und H₃ am Ende der Sektoren für den zweiten Speicherbereich, d. h. am Ende des Sektors S_0,max(s)-1 wie in 2 skizziert ist.
3 lässt die Struktur der logischen und physischen Abspeicherung von Seitenbäumen und Seitenteilbäumen für vier aufeinanderfolgende Revisionen R₀, R₁, R₂ und R₃ erkennen.
Die erste Revision R₀ basiert auf der Ursprungs-Datenseite P_0,0, die mit der Revisionsreferenz RR₀ referenziert wird. Die Ursprungs-Datenseite P_0,0 zeigt ihrerseits auf die Datenseite P_0,1.
Als Änderungen der revidierten Datenseite P_0,1 wurden die Änderungen 0A und 1B vorgenommen. Diese werden in dem Seitenteil PP_0,p gekennzeichnet, so dass aus diesem Seitenteil PP_0,p die Änderungen in der Revision sofort ersichtlich ist.
Der physische Seitenteil-Baum besteht aus der Revisionsreferenz RR₀, die auf die Kopie der Seite P_0,0, d. h. den Seiten-Snapshot PS_0,0 verweist, der seinerseits wieder auf dieser den Seiten-Snapshot PS_0,1 mit den Änderungen verweist.
In der folgenden Revision R₁ wurde eine weitere Datenseite hinzugefügt, so dass die Datenseite P_1,0 nunmehr in die Datenseiten P_1,1 und P_1,2 verzweigt. Der logische Seitenbaum ist beginnend von der Revisionsreferenz RR₁, die auf die Wurzel-Datenseite P_1,0 der Revision R₁ verweist, nunmehr baumartig so strukturiert, dass die Datenseite P_1,0 zwei Kinder-Datenseiten P_1,1 und P_1,2 enthält.
Als Änderungen wurden in der Kinder-Datenseite P_1,1 die Änderung „2C” und „0” und in der zweiten Kinder-Datenseite P_1,2 „0D” und „1E” vorgenommen. Diese Änderungen sind in dem Seitenteil PP_1,p entsprechend vermerkt, wobei die Revision auch noch die Änderungen des vorhergehenden Seitenteils PP_0,p der ersten Revision R₀ enthält.
Aus der Darstellung des physischen Seitenteil-Baums in 3 ist erkennbar, dass die revidierte Kinder-Datenseite PD_1,1 mit der Kinder-Datenseite PS_0,1 verwandt ist. Diese Kinder-Datenseite der Revision R₁ enthält allerdings keine vollständigen Dateninhalte, sondern nur die geänderten Daten, so dass der vollständige Inhalt der Kinder-Datenseite aus der Kinder-Datenseite PS_0,1 der vorhergehenden Revision R₀ und den Änderungsinformationen abgeleitet werden kann.
In der folgenden Revision R₂ ist der Datenbaum unverändert geblieben. Es wurden daher keine Datenseiten gelöscht oder hinzugefügt. Als Änderungen wurden „1B'” und „0D'” in den Kinder-Datenseiten P_2,1 und P_2,2 vorgenommen. Diese Änderungen sind zusammen mit der Änderungshistorie in den Seitenteilen PP₀, PP_1,p und PP_2,p verzeichnet.
Aus dem physischen Seitenteil-Baum ist erkennbar, dass die erste Kinder-Datenseite wiederum nur die Änderungen zur vorhergehenden Kinder-Datenseite PD_1,1 als Änderungsinformation PD_2,1 enthält. Auch die zweite geänderte Kinder-Datenseite PD_2,2 enthält nur die Änderungsinformation in Form der Deltas zur vorhergehenden Datenseite PS_1,2 der vorhergehenden Referenz R₁.
Bei der nächsten Revision R₃ wurde die erste Kinder-Datenseite P_3,1 zum vorhergehenden Revision P_2,1 nicht geändert. Allerdings wurde aus den Änderungsinformationen PD_1,1 und PD_2,1 auf der Basis des letzten verfügbaren Snapshots PS0,1 ein Snapshot PS_3,1 abgeleitet, der nunmehr den vollständigen Dateninhalt der Kinder-Datenseite P_3,1 enthält.
In der zweiten Kinder-Datenseite P_3,2 wurde im Vergleich zur vorherigen Revision eine Änderung „0D” vorgenommen. Diese Kinder-Datenseite P_3,2 wurde physisch nur als Änderungs-Datenseite PD_3,2 abgespeichert.
Weiterhin wurde eine dritte Kinder-Datenseite P_3,3 mit den Änderungen „0F” und „1G” hinzugefügt.
4 lässt ein Zustandsdiagramm bei der Durchführung des Verfahrens zur Speicherung einer Mehrzahl von Revisionen von baumstrukturartig verknüpften Datenfamilienteilen erkennen.
In dem sogenannten „Wipe”-Zustand werden beispielsweise alle Sektoren einmal mit Zufallsdaten überschrieben, die nicht kodiert sind.
In dem Initialisierungs-Zustand „init” werden die Datenspeicher LD₁, LD₂ und ein Masterschlüssel MK durch den Nutzer ausgewählt. Weiterhin wird eine Zusatzkennung SLT_h unter Verwendung des Salting-Prozesses gewählt und ein Schlüssel K aus dem Masterschlüssel MK und der Zusatzkennung SLT_h abgeleitet. Ein Token HT_h wird auf den durch den HMAC-SHA-256_k (CONF_h)-Algorithmus vorgegebenen Wert gesetzt. Die n-te Kopie des Headers H_h wird auf einen durch die Bedingung SLT_h verknüpft mit CTR-AES-256_k (CONF_h) verknüpft mit HT_h vorgegebenen Wert gesetzt.
Die Header H₀, H₁, H₂ und H₃ werden dann synchron geschrieben und verifiziert.
Im Falle eines Verifikationsfehlers wird ein Neustart des Initialisierungs-Zustands veranlasst.
Der sogenannte Start-Zustand „Start” erfolgt nach der Initialisierung. Hierbei werden der Datenspeicher LD₁, der Datenspeicher LD₂ und der Masterschlüssel MK durch den Nutzer bereitgestellt. Dann werden die Header H₀, H₁, H₂ und H₃ ausgelesen und die Zusatzkennung SLT_h durch Vergleich mit den in den Headern H₀, H₁, H₂ und H₃ abgelegten Zusatzkennungen verifiziert. Ein Knotenschlüssel wird aus dem Masterschlüssel MK und der Zusatzkennung SLT_h abgeleitet und die Header H₀, H₁, terschlüssel MK und der Zusatzkennung SLT_h abgeleitet und die Header H₀, H₁, H₂ und H₃ zur Überprüfung des Tokens HT_h mit dem Algorithmus HMAC-SHA-256_k(CONF_h) verifiziert.
Weiterhin wird die Revisionsreferenz RR_max(r)-1 auf den zweiten Datenspeicher LD₂ gesucht und durch Vergleich mit der auf dem ersten Datenspeicher LD₁ abgelegten Revisionsreferenz RR_max(r)-1 verifiziert. Ein Fehler bei der Verifikation verursacht einen Übergang in den Wiederherstellungs-Zustand „recover”.
Im Wiederherstellungs-Zustand „recover” wird der Header H wiederhergestellt. Dies kann anhand der verfügbaren Kopien des Headers erfolgen. Weiterhin wird der Inhalt auf dem ersten und/oder zweiten Datenspeicher LD₁ und LD₂ unter Verwendung der verfügbaren redundanten Daten wiederhergestellt. Nach der Wiederherstellung der Information erfolgt ein Sprung in den Stop-Zustand „stop”.
Der Ausführungs-Zustand „run” wird jedes Mal durchgeführt, wenn eine Revision übergeben wird. Hierbei werden folgende Punkte abgearbeitet.
Im ersten Punkt wird die letzte Revision R_max(r) synchron auf dem ersten Datenspeicher LD₁ geschrieben. Im folgenden Schritt wird die Revisionsreferenz RR_max(r) auf die letzte Revision R_max(r) auf den ersten Datenspeicher LD₁ verifiziert. Sodann wird die Revisionsreferenz RR_max(r) synchron auf den zweiten Datenspeicher LD₂ geschrieben und dort verifiziert. Anschließend wird im fünften Schritt die Nummer der verfügbaren Revision R_max(r), d. h. die fortlaufende Nummer der aktuellen Revision inkrementiert auf max(r) + 1.
Ein Fehler bei der Überprüfung führt zu einer zweiten Serialisierung beginnend mit Schritt 1 des Ausführungs-Zustands „run”.
Wiederum erfolgt am Ende ein Sprung in den Stop-Zustand, bei der neue Änderungen nicht länger zugelassen werden. Bislang nicht abgespeicherte Änderungen werden wie in dem Ausführungs-Zustand beschrieben abgespeichert.
Falls in dem Ausführungs-Zustand der fünfte Punkt der Inkrementierung der Nummer für die aktuelle Revision nicht innerhalb einer einstellbaren Zeit erreicht wurde, erfolgt sofort ein Stop.
5 lässt das Verfahren der Serialisierung einer im Speicher abgelegten Datenseite auf ein Gerät, wie z. B. eine Hard Disk, als Flussdiagramm erkennen.
Eine im Speicher abgelegte Datenseite wird serialisiert. Die serialisierten Datenseitenteile werden komprimiert und die komprimierten Datenseiteteile werden authentifiziert, verschlüsselt und anschließend auf das Gerät, wie beispielsweise eine Hard Disk oder einen anderen Datenträger, geschrieben.
Das Auslesen von Datenseitenteilen aus dem Gerät erfolgt, indem die Dateninhalte zunächst gelesen und die verschlüsselten Datenseitenteile entschlüsselt und authentifiziert werden. Die komprimierten Datenseitenteile werden anschließend dekomprimiert und liegen als serialisierte Datenseitenteile nunmehr unverschlüsselt vor. Nach einer Deserialisierung kann die Datenseite dann in einem Speicher, insbesondere einem flüchtigen Datenspeicher RAM, abgelegt werden.
6 lässt eine Skizze für eine beispielhafte Art zur Abspeicherung von Knoten erkennen.
In der ersten Spalte ist der Zustand der Datenseiten P_3,0 zur Zeit der Revision R₃ dargestellt. Die Seite P_3,0 entspricht der Seitenkopie PS_3,0. Der Knoten bei der Position 1 wurde vor der Revision R₃ gesetzt. Der Knoten ist vom Typ 22 und hat den Wert <example>. Der Knoten bei der Position 2 wurde vor der Revision R₃ gesetzt. Der Knoten ist vom Typ 33 und hat den Wert „text”. Der Knoten an der Position 6 wurde während der Revision R₃ gelöscht. Der gelöschte Knoten war vom Typ 33.
In der zweiten Spalte ist der Zustand der Datenseite P_4,0 zur Zeit der Revision R₄ dargestellt. Die Änderungen sind in der Differenz-Datenseite PD_4,0 abgelegt. Der Knoten bei der Position 1 wurde vor der Revision R₄ gesetzt. Der Knoten ist vom Typ 22 und hat den Wert <example>. Der Knoten bei der Position 2 wurde während der Revision R4 gesetzt. Der Knoten ist nun vom Typ 33 und hat den Wert „new text”.

Claims

Verfahren zur Speicherung einer Mehrzahl von Revisionen (R_r) von baumstrukturartig verknüpften Datenfamilienteilen, die jeweils eine Anzahl von miteinander baumartig verknüpfter Datenseiten (P_r) mit einer zentralen Eltern-Datenseite (PP_r,0) und von dieser ausgehenden Kinder-Datenseiten (PP_r,x) haben, wobei für jede Revision (R_r) ein Haupt-Referenzzeiger (RR_r) auf die Eltern-Datenseite (PP_r,0) der jeweiligen Datenseite (P_r) in einer separat abgespeicherten Liste bereitgestellt wird und die Datenseiten (P_r) mindestens einen Seiten-Referenzzeiger (RR_r,p) auf logisch unmittelbar nachfolgend verknüpfte Kinder-Datenseiten (PP_r,x) haben, gekennzeichnet durch Abspeichern von Knotenänderungsinformationen für jede Revision über Änderungen von eine Referenz auf logisch unmittelbar nachfolgend verknüpfte Kinder-Datenseiten (PP_r,x) definierende Knoten der Struktur baumartig verknüpfter Datenfamilienteile.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Knotenänderungsinformationen das Hinzufügen neuer Knoten, das Löschen von Knoten und/oder die Änderung von Knoten kennzeichnen.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass Kinder-Datenseiten (PPr, x) die Änderung der entsprechenden Kinder-Datenseite (PPr, x) einer unmittelbar vorhergehenden Revision in Form von Differenzdaten (PDr, x) enthalten.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass Datenseiten (Pr) den vollständigen, optional in der jeweiligen Revision modifizierten Dateninhalt enthalten.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Hauptreferenzzeiger (RRr) oder Kopien davon auf einem weiteren Datenspeichermedium (LD₂) separat von den referenzierten Datenseiten (Pr) abgelegt sind.
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Hauptreferenzzeiger (RRr) oder Kopien davon in Sektoren (S0,s) eines Datenspeichermediums (LD0) getrennt von den Sektoren (S0,s) desselben Datenspeichermediums (LD0) abgelegt sind, in denen die referenzierten Datensätze (Pr) gespeichert sind.
Verfahren nach einem der vorhergehenden Ansprüche, gekennzeichnet durch Absichern der Speicherung der Revisionen (Rr) von Datenfamilien durch Verschlüsselung, indem ein geheimer Masterschlüssel (MK) definiert und unabhängig von dem Masterschlüssel (MK) eine Zusatzkennung (SLT) generiert (Salting) wird und aus dem Masterschlüssel (MK) und der Zusatzerkennung (SLT) ein Schlüssel (K) abgeleitet wird (Stretching), sowie für jede Datenseite (PPr, x) ein jeweils einzigartiger Ad-Hoc-Schlüssel (N) und ein Zähler (CTR) aus Ergebnissen der Ver-/Entschlüsselungsalgorithmen übergeordneter Knoten zur Verschlüsselung, Entschlüsselung und Authentifizierung mindestens der zugeordneten Hauptreferenzzeiger, der Datenseiten und mindestens eines Kopfteils für die Gesamtheit der Revisionen (Rr) der gespeicherten Datenfamilien abgeleitet wird.
Verfahren nach einem der vorhergehenden Ansprüche, gekennzeichnet durch Auslesen von gespeicherten Revisionen (R_r) von Datenseiten (P_r), gekennzeichnet durch – Verifizieren der Übereinstimmung gespeicherter Kopien eines Kopfteils (H_h) für die Gesamtheit der Revision (R_r) gespeicherter Datenfamilien, – Verifizieren der Übereinstimmung einer in einem separaten Datenspeichermedium (LD₂) oder auf einem separaten Sektor (S_0,s) eines Datenspeichermediums (LD₀) abgelegten Kopie eines Hauptreferenzzeigers (RR_r) für die aktuelle Revision (R_max(r)) mit einem Hauptreferenzzeiger (RR_r) der aktuellen Revision (R_max(r)), die auf einem Sektor (S_0,s) des Datenspeichermediums (LD₂) zusammen mit den zugehörigen Datenseiten (P_r) der Revision (R_r) abgelegt sind, – Zugreifen auf Datenseiten (PP_r,x) gewünschter Revisionen (R_r) über im Hauptreferenzzeiger (RR_r) für die entsprechende Revision (R_r) und den Seitenreferenzzeigern (PR_r,p) enthaltenen Zeigern und – Auswerten von Knotenänderungsinformationen für jede Revision (R_r) über Änderungen von eine Referenz auf logisch unmittelbar nachfolgend verknüpfte Kinder-Datenseiten (PP_r,x) definierende Knoten der Struktur baumartig verknüpfter Datenfamilienteile.
Verfahren nach Anspruch 8, gekennzeichnet durch Zugreifen auf gewünschte Revisionen (R_r) mittels eines binären Suchalgorithmus über die Liste der Hauptreferenzzeiger (RR_r), wobei eine Suche an Hand der Revisionsnummer und/oder eines im Hauptreferenzzeiger (RR_r) gespeicherten Zeitstempels erfolgt.