DE202014010898U1

DE202014010898U1 - Hierarchische Stückelung von Objekten in einem dezentralen Speichersystem

Info

Publication number: DE202014010898U1
Application number: DE202014010898.6U
Authority: DE
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2013-12-27
Filing date: 2014-12-24
Publication date: 2017-01-13
Anticipated expiration: 2024-12-25
Also published as: CN105940396B; EP3087513B1; EP3087513A1; AU2014369830B2; US20150186043A1; US9400828B2; US20160034549A1; JP2017500670A; EP3087513A4; CA2935215C; JP6479020B2; AU2014369830A1; WO2015100416A1; US9158472B2; CA2935215A1; CN105940396A

Abstract

Computersystem für die Platzierungsverwaltung von Objektreplikaten in einem dezentralen Speichersystem mit einer Vielzahl von Instanzen, wobei jede jeweilige Instanz das Folgende umfasst: einen oder mehrere Prozessoren; Speicher; und ein oder mehrere im Speicher abgelegte Programme, wobei das eine oder die mehreren Programme durch einen oder mehrere Prozessoren ausführbare Instruktionen für die Durchführung der nachfolgenden Schritte umfasst: in einer ersten Instanz des dezentralen Speichersystems, das Verfügen über einen oder mehrere Prozessoren und über Speicher, worin der Speicher ein oder mehrere Programme für die Ausführung durch einen oder mehrere Prozessoren speichert: das Empfangen eines ersten Objekts, das einer Erstplatzierungs-Richtlinie zugewiesen ist, worin die Erstplatzierungs-Richtlinie Kriterien dafür festlegt, wo im dezentralen Speichersystem Replikate des ersten Objekts gespeichert werden; das Spalten eines Objekts in eine Vielzahl von Objektsegmenten und die Spaltung eines ersten Objektsegments in eine Vielzahl von Blöcken; das Speichern der Vielzahl von Blöcken in einem ersten Journal, dessen zugewiesene Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie übereinstimmt; das Speichern globaler Metadaten für das erste Objekt, worin die globalen Metadaten eine Liste der Vielzahl von Objektsegmenten beinhaltet und worin die Liste eine jeweilige Kennung für jedes der Objektsegmente beinhaltet; das Speichern lokaler Metadaten für das erste Objektsegment, worin die lokalen Metadaten eine Blockliste beinhalten, die jeden Block einer ersten Vielzahl von Blöcken identifiziert und worin die lokalen Metadaten dem ersten Journal zugewiesen werden; das Replizieren des ersten Journals an eine zweite Instanz des dezentralen Speichersystems in Übereinstimmung mit der Erstplatzierungs-Richtlinie, worin die globalen Metadaten aktualisiert werden, um die Replizierung widerzuspiegeln, wohingegen die lokalen Metadaten durch die Replizierung unverändert bleiben.

Description

TECHNISCHES GEBIET
Die offenbarten Implementierungen beziehen sich im Allgemeinen auf dezentrale Speichersysteme und spezifischer auf die Spaltung von Objekten in Segmente (chunks) und auf die hierarchische Speicherung dieser Segmente. Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind dabei, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
HINTERGRUND
Die Speicherung umfangreicher Datenmengen hat sich von einer zentralisierten Dienst-Architektur auf dezentrale Speichersysteme verlagert. Aus Gebrauchscomputern gebaute dezentrale Speichersysteme bieten Hochperformanz, Verfügbarkeit und Skalierbarkeit zu einem Bruchteil der Kosten monolithischer Disk-Arrays. Daten werden über multiple Instanzen eines dezentralen Speichersystems hinweg an verschiedenen geografischen Standorten repliziert, was ihre Verfügbarkeit erhöht und die Distanz zu Clients im Netzwerk verringert.
In einem dezentralen Speichersystem werden Objekte aufgrund von Sachzwängen dynamisch in mehreren Instanzen des dezentralen Speichersystems platziert (d. h. erstellt, gelöscht und/oder bewegt). Es existieren wenige Verfahren für die effiziente Platzierung von Objekten, die in einem weltweiten dezentralen Speichersystem, welches Trillionen von Objekten und Petabytes von Daten speichert und Dutzende über den Planeten verteilte Datenzentren beinhaltet, Gegenstand gewisser Sachzwänge sind.
Neue Formen der Visualisierung, Multimedia und andere datenintensive Anwendungen verwenden sehr große Objekte, die hunderte Gigabytes oder größer sein können. Diese großen Objekte zu verwalten schafft zusätzliche Komplexität für ein dezentrales Speichersystem. Zum einen erfolgt der Upload dieses Objekts in ein dezentrales Speichersystem typischerweise in einem Streaming-Modus, indem Objekte in Segmente aufgespalten und jedes Segment individuell geschrieben wird. Dies kann lange Verzögerungen beim Upload verursachen, was durch potentielle Client- und Server-Fehler noch verschärft wird. Darüber hinaus können Segmente zwecks erhöhter operativer Effizienz in größeren Bruchstücken (shards) aggregiert werden. Die Begriffe „Bruchstück” und „Journal” können in diesem Dokument synonym verwendet werden. Folglich ist der effiziente Upload großer Objekte von zunehmender Wichtigkeit für die Speicherindustrie, welche von der Notwendigkeit umfangreicher Systeme vorangetrieben wird, die es Clients erlauben, sich mit jedem zu einer gegebenen Zeit verfügbaren Cluster zu verbinden. Zusätzlich macht das Volumen der Metadaten eines einzelnen Objekts (z. B. 25.000 Segmente für eine 100-Gigabyte-Datei, wobei jedes Segment 4 Megabytes groß ist) die Replizierung und Komprimierung weniger effizient.
KURZDARSTELLUNG
Offenbarte Implementierungen verteilen den Upload großer Objekte an mehrere Speicherorte gleichzeitig. In diesem Dokument werden Speicherorte als „Bruchstücke”, „aggregierte Bruchstücke” oder „Journals” bezeichnet. Dieses Schema wird implementiert, indem ein großes Objekt in verschiedene Segmente gespalten wird, welche jeweils in einen unterschiedlichen Speicher-Cluster (der an verschiedenen geografischen Standorten liegen kann) hochgeladen werden können. Wenn ein Bruchstück während des Uploads unzugänglich wird (z. B. weil das Bruchstück „voll” ist oder die Instanz, in welcher das Bruchstück gespeichert ist, vom Netz geht), schaltet der Client auf ein neues Bruchstück um, welches sich in einem anderen Cluster befinden kann. Dieses Schema verlangt es nicht, nach Beginn am selben Bruchstück festzuhalten. Ein beendetes Objekt wird durch eine geordnete Liste von Segmentreferenzen dargestellt.
In einigen Schemata ist ein Segment die grundlegende Speichereinheit und wird der Standort eines jeden Segments in den globalen Metadaten gespeichert. Für sehr große Objekte resultiert dieses Schema in einer signifikanten Menge an Metadaten für ein einzelnes Objekt, die auf globaler Ebene gespeichert werden. Deshalb benutzen einige Implementierungen ein hierarchisches Stückelungsschema, das die Menge der für jedes Objekt gespeicherten globalen Metadaten verringert. Innerhalb einer hierarchischen Implementierung wird der Begriff „Segment” verwendet, um eine Spaltung auf höchster Ebene zu bezeichnen, welche über auf globaler Ebene gespeicherte, korrespondierende Metadaten verfügt. In diesen Implementierungen wird der Begriff „Block” verwendet, um eine grundlegende tatsächliche Speichereinheit (z. B. 2 Megabytes oder 8 Megabytes) zu beschreiben. Die Blöcke werden lokal für jedes Bruchstück verwaltet. In einem nichthierarchischen System wird die Bezeichnung „Segment” verwendet, um beide Konzepte zu beschreiben, da die grundlegende Speichereinheit die Grundeinheit dafür ist, welche globalen Metadaten gespeichert werden.
Hierarchische Stückelung kann auf verschiedene Arten implementiert werden. In einigen Implementierungen umfasst jedes Segment eine Blockliste sogar dann, wenn es nur einen einzigen Block gibt. In diesen Implementierungen existiert immer ein zusätzliches Hierarchielevel für die Suche von Daten, die mit einem Segment korrespondieren. Andere Implementierungen verwenden ein Hybrid-Schema, sodass eine Hierarchie nur dann existiert, wenn sie für große Segmente benötigt wird. In dieser Hybrid-Implementierung können kleine Objekte ein einzelnes Segment umfassen, das mit einem einzelnen Block korrespondiert. Auf der anderen Seite ist dann jedes Segment eines größeren Objekts eine Liste von Blöcken.
Die offenbarten hierarchischen Schemata verringern die Menge an globalen Metadaten, was die Kosten der Objektverwaltung oder -verlagerung von einem Speichercluster in einen anderen verringert. Dort wo die Objektsegmente auf globaler Ebene verwaltet werden, werden die Blöcke innerhalb eines Segments auf lokaler Bruckstückebene verwaltet, sodass die Objektmetadaten typischerweise nur eine Segmentreferenz pro Bruchstück enthalten.
In einigen Implementierungen erfolgt der Upload-Prozess in den folgenden Schritten: (1) Finde einen verfügbares Bruchstück für den Upload; (2) schreibe Daten in das aktuelle Bruchstück bis entweder das Bruchstück unverfügbar (z. B. voll) ist oder es keine weiteren Daten mehr gibt; (3) füge die aktuelle Segmentreferenz der geordneten Segmentliste hinzu; (4) wenn der Objektupload abgeschlossen ist, schließe das Objekt; (5) wiederhole die Schritte beginnend bei Schritt (1) für den Rest des Objekts.
In einigen Implementierungen erfolgt das Auslesen eines Objekts auf dem Speicher in den folgenden Schritten: (1) finde, für das gewünschte Objekt, den Satz von Segmentreferenzen (es gibt immer wenigstens eine); (2) finde aufgrund der Segmentreferenz den Standort des Bruchstücks; (3) lese die Daten aus dem/den Bruchstückstandort/en unter Verwendung der Segmentkennung und der lokalen Bruchstückmetadaten aus; (4) wiederhole die Schritte (2) und (3) für jede Segmentreferenz.
Angenommen zum Beispiel, ein Objektupload wurde durch das Beschreiben mit Daten von Bruchstück1 begonnen und dann auf Bruchstück2 umgeschaltet, als Bruchstück1 voll wurde. (Die zwei Bruchstücke Bruchstück1 und Bruchstück1 können in denselben oder unterschiedlichen Instanzen liegen.) Die Objektmetadaten (welche globaler Natur sind) bestehen aus zwei Segmentreferenzen, wohingegen jedes Bruchstück eine lokale Blockliste für jedes Segment verwaltet. Zum Beispiel könnte jedes Bruchstück eine Vielzahl von Blöcken für das Objekt speichern. In diesem Fall ist der Speicher vollständig hierarchisch: Das Objekt wird in Segmente gespalten und jedes Segment wird in Blöcke gespalten. In anderen Implementierungen kann eines der Segmente in eine Vielzahl von Blöcken gespalten werden (dieses Segment wird manchmal als „Super-Segment” bezeichnet), wohingegen ein anderes Segment aus einem einzelnen Block bestehen kann. In letzterem Fall kann die Segmentkennung eine Blockkennung sein.
Weil Bruchstück1 und Bruchstück2 voneinander unabhängig sind, können ihre Replikate in verschiedenen Instanzen gespeichert sein. Zum Beispiel kann Bruchstück1 in der Instanz1 und der Instanz2 gespeichert sein, wohingegen Bruchstück2 in der Instanz1 und der Instanz3 gespeichert sein kann.
Die offenbarte Methodik verbessert in erheblichem Umfang sowohl die Uploadserviceverfügbarkeit als auch die Speichereffizienz. Diese Methodik unterstützt sowohl fortsetzbare Uploads (z. B. wenn eine Instanz während des Uploads eines großen Objekts vom Netz geht) als auch das Umschalten zu einem neuen Bruchstück mitten im Upload (z. B. wenn ein Bruchstück voll wird). Zusätzlich unterstützt diese Methodik das Schreiben mehrerer Bruchstücke gleichzeitig, was die Performance bei sehr großen Objekten erheblich verbessert. In einigen Implementierungen können Daten für ein einzelnes Objekt auf zwei oder mehr unterschiedliche Bruchstücke in verschiedenen Instanzen gleichzeitig geschrieben werden, ebenso auf zwei oder mehr Bruchstücke in derselben Instanz und sogar innerhalb eines einzigen Journals können zwei oder mehr Prozess-Threads unterschiedliche Datenblöcke in das einzelne Journal schreiben. Natürlich ist ein dezentraler Upload durch die verfügbaren Ressourcen beschränkt. Das dezentrale Speichersystem hat viele verschiedene Clients, die zur selben Zeit Objekte hochladen, daher ist es einem einzelnen sehr großen Objekt eines Clients nicht gestattet, zu viele der verfügbaren Ressourcen zu verbrauchen.
Gemäß einiger Implementierungen wird ein Verfahren für die Platzierungsverwaltung von Objektreplikaten in einem dezentralen Speichersystem in einer ersten Instanz des dezentralen Speichersystems durchgeführt. Die erste Instanz hat einen oder mehrere Server, von denen jeder über einen oder mehrere Prozessoren und über Speicherplatz verfügt. Der Speicher speichert ein oder mehrere Programme zur Ausführung durch einen oder mehrere Prozessoren. Die erste Instanz empfängt ein erstes Objekt, das einer Erstplatzierungs-Richtlinie zugewiesen ist. Die Erstplatzierungs-Richtlinie legt Kriterien dafür fest, wo Replikate des ersten Objekts im dezentralen Speichersystem gespeichert werden. In einigen Implementierungen bestimmt jede Platzierungs-Richtlinie eine angestrebte Zahl von Objektreplikaten und Zielorten für diese Replikate. Die erste Instanz spaltet das Objekt in eine Vielzahl von Objektsegmenten und spaltet das erste Objektsegment der Vielzahl von Objektsegmenten in eine Vielzahl an Blöcken. Die erste Instanz speichert die Vielzahl von Blöcken in einem ersten Journal, dessen zugewiesene Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie übereinstimmt. Die erste Instanz speichert globale Metadaten für das erste Objekt, das eine Liste der Vielzahl von Objektsegmenten beinhaltet. Die Liste beinhaltet eine jeweilige Kennung für jedes der Objektsegmente. Die erste Instanz speichert lokale Metadaten für das erste Objektsegment, welches eine Blockliste beinhaltet, die jeden Block der Vielzahl von Blöcken eindeutig identifiziert. Die lokalen Metadaten werden dem ersten Journal zugewiesen. Das erste Journal wird anschließend in einer zweiten Instanz des dezentralen Speichersystems in Übereinstimmung mit der Erstplatzierungs-Richtlinie repliziert. Die globalen Metadaten werden aktualisiert, um die Replizierung widerzuspiegeln, wohingegen die lokalen Metadaten durch die Replizierung unverändert bleiben.
Gemäß einiger Implementierungen wird ein Verfahren für die Platzierungsverwaltung von Objektreplikaten in einem dezentralen Speichersystem an einer ersten Instanz des dezentralen Speichersystems durchgeführt. Die erste Instanz hat einen oder mehrere Server, von denen jeder über einen oder mehrere Prozessoren und über Speicherplatz verfügt. Der Speicher speichert ein oder mehrere Programme zur Ausführung durch einen oder mehrere Prozessoren. Ein oder mehr Journals werden für die Speicherung von Objektsegmenten geöffnet. Jedem Journal wird eine einzelne Platzierungs-Richtlinie zugewiesen. In einigen Implementierungen bestimmt jede Platzierungs-Richtlinie eine angestrebte Zahl von Objektreplikaten und Zielorten für diese Replikate. Die erste Instanz empfängt ein erstes Objekt, das wenigstens ein erstes Objektsegment umfasst. Das erste Objekt wird einer Erstplatzierungs-Richtlinie zugewiesen. Das erste Objektsegment umfasst eine erste Vielzahl von Blöcken. Die erste Instanz speichert die erste Vielzahl von Blöcken in einem ersten Journal, dessen zugewiesene Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie übereinstimmt. Das erste Journal speichert ausschließlich Blöcke von Objekten, deren Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie übereinstimmt. Die erste Instanz speichert globale Metadaten für das erste Objekt, welches eine erste Liste von Objektsegmenten beinhaltet, die mit dem ersten Objekt korrespondiert. Die erste Liste beinhaltet eine Kennung für das erste Objektsegment. Die erste Instanz speichert außerdem lokale Metadaten für das erste Objektsegment, welches eine Blockliste beinhaltet, die jeden Block der ersten Vielzahl von Blöcken eindeutig identifiziert. Die lokalen Metadaten werden dem ersten Journal zugewiesen. Für das erste Journal werden die Empfangs- und Speicheroperationen für die erste Vielzahl von Objekten wiederholt, deren zugewiesene Platzierungs-Richtlinien mit der Erstplatzierungs-Richtlinie übereinstimmt, bis dass eine erste Beendigungsbedingung eintritt. In einigen Implementierungen tritt die erste Beendigungsbedingung nach einer zuvor festgelegten Zeitspanne ein, oder nachdem das erste Journal einen zuvor festgelegten Größengrenzwert überschritten hat. Nachdem die erste Beendigungsbedingung eintritt, wird das erste Journal geschlossen, wodurch die Speicherung weiterer Blöcke im ersten Journal verhindert wird. Anschließend wird das erste Journal in einer zweiten Instanz des dezentralen Speichersystems in Übereinstimmung mit der Erstplatzierungs-Richtlinie repliziert. Die globalen Metadaten werden aktualisiert, um die Replizierung widerzuspiegeln, wohingegen die lokalen Metadaten durch die Replizierung unverändert bleiben.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist eine konzeptuelle Veranschaulichung eines dezentralen Speichersystems gemäß einiger Implementierungen.
2 ist ein Blockdiagramm, das die Elemente eines dezentralen Speicher systems gemäß einiger Implementierungen veranschaulicht.
3 ist ein Blockdiagramm eines Servers gemäß einiger Implementierungen.
4 ist ein Blockdiagramm eines Instanzenservers gemäß einiger Implementierungen.
5 veranschaulicht die Verwendung eines Journals für die Speicherung von Objektsegmenten in Übereinstimmung mit einigen Implementierungen.
6 veranschaulicht, wie einige Implementierungen die Speicherung eines neuen Objekts bewältigen.
7 veranschaulicht die Struktur eines offenen Journals in Übereinstimmung mit einigen Implementierungen.
8 veranschaulicht, was mit Objektmetadaten und Journalmetadaten geschieht, wenn ein Journal von einer an eine andere Instanz repliziert wird, in Übereinstimmung mit einigen Implementierungen.
9A–9C veranschaulichen ein Verfahren der Platzierungsverwaltung von Objektreplikaten in einem dezentralen Speichersystem in Übereinstimmung mit einigen Implementierungen.
10A und 10B veranschaulichen, wie Objektsegmente weiter in Blöcke aufgespalten werden, in Übereinstimmung mit einigen Implementierungen.
11A–11D veranschaulichen ein alternatives Verfahren der Platzierungsverwaltung von Objektreplikaten in einem dezentralen Speichersystem in Übereinstimmung mit einigen Implementierungen.
2 veranschaulicht die Speicherung von Segmenten in einem teilweise hierarchischen, dezentralen Speichersystem in Übereinstimmung mit einigen Implementierungen.
Gleichnamige Referenzziffern beziehen sich über alle Zeichnungen hinweg auf ihnen entsprechende Bestandteile.
BESCHREIBUNG VON IMPLEMENTIERUNGEN
Bevor Verfahren für die Platzierungsverwaltung von Objekten in einem dezentralen Speichersystem besprochen werden, ist es lehrreich, ein Musterbeispiel eines Systems vorzustellen, in dem diese Techniken verwendet werden.
Überblick dezentraler Speichersysteme
Wie in 1 veranschaulicht, beschreiben die offenbarten Implementierungen ein dezentrales Speichersystem. Es existieren multiple Instanzen 102-1, 102-2, ... 102-N an verschiedenen Standorten auf der Erde 100, miteinander verbunden durch Netzwerkkommunikationsverbindungen 104-1, 104-2, ... 104-M. Beachten Sie, dass eine „Instanz” in dieser Patentschrift auch als „Speicherort” bezeichnet wird. Beachten Sie weiterhin, dass eine oder mehre Instanzen (Speicherorte) sich an einem bestimmten physischen Standort (z. B. einem Gebäude, einem Gebäudekomplex innerhalb einer vorgegeben Entfernung voneinander etc.) befinden können. In einigen Implementierungen korrespondiert mit einer Instanz (etwa Instanz 102-1) ein Datenzentrum. In einigen Implementierungen sind verschiedene Instanzen physisch im selben Datenzentrum untergebracht. Eine einzelne Implementierung kann sowohl individuelle Instanzen an verschiedenen geografischen Standorten als auch einen oder mehre Instanzen-Cluster haben, wobei jeder Cluster eine Vielzahl von Instanzen beinhaltet und die Instanzen innerhalb eines jeden Clusters sich an einem einzelnen geografischen Standort befinden.
Obwohl das konzeptuelle Diagramm der 1 eine bestimmte Anzahl an Netzwerkkommunikationsverbindungen 104-1 etc. veranschaulicht, können typische Implementierungen über mehr oder weniger Netzwerkkommunikationsverbindungen verfügen. In einigen Implementierungen existieren zwei oder mehr Netzwerkkommunikationsverbindungen zwischen demselben Instanzenpaar. Zum Beispiel stellen die Netzwerkkommunikationsverbindungen 104-5 und 104-6 eine Netzwerkverbindung zwischen den Instanzen 102-2 und 102-6 bereit. In einigen Implementierungen beinhalten die Netzwerkkommunikationsverbindungen eine Glasfaserverkabelung. In einigen Implementierungen verwenden einige der Netzwerkkommunikationsverbindungen kabellose Technologien, wie etwa Mikrowellen. In einigen Implementierungen verfügt jede Netzwerkkommunikationsverbindung über eine spezifische Bandbreite und/oder über spezifische Kosten für die Verwendung dieser Bandbreite. In einigen Implementierungen werden Statistiken betreffend des Datentransfers über eine oder mehrere der Netzwerkkommunikationsverbindungen hinweg gepflegt, einschließlich der Durchgangsrate, Verfügbarkeitszeiten, Verlässlichkeit der Verbindungen etc. Jede Instanz verfügt typischerweise über Datenspeicher und zugewiesene Datenbanken und nutzt eine Servercomputerfarm („Instanzenserver”, wie in 4 veranschaulicht) um alle Aufträge durchzuführen. In einigen Implementierungen verfügen eine oder mehrere Instanzen des dezentralen Speichersystems über eingeschränkte Funktionalität. Zum Beispiel kann die eingeschränkte Funktionalität eine Rolle als Repeater für Datentransmissionen zwischen anderen Instanzen beinhalten. Beachten Sie, dass Instanzen eingeschränkter Funktionalität möglicherweise einige, keine oder alle der Datenzentren beinhalten können.
2 ist ein Blockdiagramm, das Elemente eines dezentralen Speichersystems 200 gemäß einiger Implementierungen veranschaulicht. Das dezentrale Speichersystem 200 beinhaltet die Instanzen 102-1, 102-2, 102-3, 102-4, .... 102-N. Eine entsprechende Instanz 102-1 beinhaltet ein Replikationsmodul 220, das Objektsegmente 238 zwischen Instanzen repliziert. In einigen Implementierungen werden die Objektsegmente 238 in Datenspeichern 224 der entsprechenden Instanz 102-1 gespeichert. Jedes Objektsegment 238 umfasst ein Objekt 226 oder einen Teil eines Objekts 226, wie in 6 veranschaulicht. Die Datenspeicher 224 können dezentrale Datenbanken, Dateisysteme, Sicherungsbänder und jeden anderen Typ von Speichersystem oder -gerät beinhalten, der dazu in der Lage ist, Objekte zu speichern. In einigen Implementierungen verwendet das Replikationsmodul 220 eine oder mehrere Replikationswarteschlangen 222-1, 222-2, ... 222-L, um die Objekte 226 oder die Journals 230 zu replizieren. Replikationsanfragen für zu vervielfältigende Objekte oder Journals werden in der Replikationswarteschlange 222 platziert und die Objekte oder Journals werden repliziert, sobald Ressourcen (z. B. Bandbreite) verfügbar werden. In einigen Implementierungen haben Replikationsanfragen in der Replikationswarteschlange 222 zugewiesene Prioritäten und die Replikationsanfrage mit der höchsten Priorität wird abgearbeitet, sobald Bandbreite verfügbar wird.
In einigen Implementierungen erstellt und löscht ein Hintergrund-Replikationsprozess Kopien eines Objekts oder eines Journals auf Grundlage der Platzierungs-Richtlinie 212 und der Zugriffsdaten 210 und/oder des vom Statistik-Server 208 bereit gestellten globalen Zustands 211. Die Platzierungs-Richtlinie 212 bestimmt, wie viele Kopien eines Objekts erwünscht sind, wo die Kopien liegen sollen und in welchem Typ Datenspeicher die Daten gespeichert werden sollen. Unter Verwendung der Platzierungs-Richtlinie 212 gemeinsam mit den Zugriffsdaten 210 (z. B. Daten bezüglich von Speicherstandorten, an denen auf Objektreplikate zugegriffen wurde, Zeiten zu denen auf Objektreplikate an Speicherstandorten zugegriffen wurde, Häufigkeit der Zugriffe auf Objekte an den Speicherstandorten etc.) und/oder dem vom Statistik-Server 208 bereitgestellten globalen Zustand 211 ermittelt ein Standortzuweisungs-Daemon (location assignment daemon, LAD) 206, wo neue Kopien eines Objekts oder Journals erstellt und welche Kopien gelöscht werden können. Sobald neue Kopien erstellt werden, werden Replikationsanfragen in die Replikationswarteschlange 222 eingefügt. In einigen Implementierungen verwaltet der LAD 206 Replikate von Objekten oder Journals auf globaler Ebene für das dezentrale Speichersystem 200. Mit anderen Worten existiert nur ein LAD 206 im dezentralen Speichersystem 200. Die Verwendung der Platzierungs-Richtlinie 212 und der Betrieb des LAD 206 werden weiter unten in größerem Detail beschrieben.
Beachten Sie, dass eine entsprechende Platzierungs-Richtlinie 212 allgemein eine Anzahl an zu speichernden Objektreplikaten bestimmen kann, weiterhin in welchen Typen Datenspeichern die Replikate gespeichert werden sollen, Speicherstandorte, an denen die Kopien gespeichert werden sollen etc. In einigen Implementierungen beinhaltet eine entsprechende Platzierungs-Richtlinie 212 aus der Gruppe ausgewählte Kriterien für ein Objekt, bestehend aus einer Mindestanzahl an Objektreplikaten, die im dezentralen Speichersystem vorhanden sein müssen, einer Maximalanzahl an Objektreplikaten, die im dezentralen Speichersystem vorhanden sein dürfen, Typen von Speichergeräten, in denen die Objektreplikate gespeichert werden sollen, Standorte an denen die Objektreplikate gespeichert werden sollen, Standorte an denen die Objektsreplikate nicht gespeichert werden dürfen und ein Altersspektrum für das Objekt, innerhalb dessen die Platzierungs-Richtlinie auf das Objekt Anwendung findet. Zum Beispiel kann eine Erstplatzierungs-Richtlinie bestimmen, dass jedes Objekt in einer Webmail-Anwendung eine Mindestanzahl von 2 Replikaten und eine Höchstanzahl von 5 Replikaten haben muss, worin die Objektreplikate in Datenzentren außerhalb von China gespeichert werden können und mindestens 1 Replikat jedes Objekts auf Band gespeichert werden muss. Eine zweite Platzierungs-Richtlinie für die Webmail-Anwendung kann außerdem bestimmen, dass für jedes Objekt, das älter als 30 Tage ist, eine Mindestanzahl von einem Replikat und eine Höchstanzahl von drei Replikaten im dezentralen Speichersystem 200 gespeichert werden, worin die Objektreplikate in Datenzentren außerhalb von China gespeichert werden können und wenigstens ein Replikat jedes Objekts auf Band gespeichert werden muss.
In einigen Implementierungen interagiert ein Anwender 240 mit einem Anwendersystem 242, wobei es sich um ein Computersystem oder ein anderes Gerät handeln kann, das in der Lage dazu ist, einen Webbrowser 244 auszuführen. Eine Benutzeranwendung 246 läuft in einem Webbrowser und greift auf eine Funktionalität zurück, welche der Datenbank-Client 248 bereitstellt, um unter Verwendung eines Netzwerks auf Daten zuzugreifen, welche im dezentralen Speichersystem 200 gespeichert sind. Beim Netzwerk kann es sich um das Internet, ein lokales Netzwerk (LAN), ein Weitverkehrsnetzwerk (WAN), ein kabelloses Netzwerk (WLAN), ein lokales Intranet oder um eine Kombination derselben handeln. In einigen Implementierungen verwendet der Datenbank-Client 248 Informationen in einem globalen Konfigurationsspeicher 204, um eine geeignete Instanz für die Beantwortung der Anfrage zu ermitteln. In einigen Implementierungen läuft die Benutzeranwendung 246 auf dem Anwendersystem 242 ohne einen Webbrowser 244. Exemplarische Benutzeranwendungen beinhalten eine E-Mail-Anwendung und eine Online-Videoanwendung.
In einigen Implementierungen speichert jede Instanz Objektmetadaten 228 für jedes der im dezentralen Speichersystem gespeicherten Objekte. Einige Instanzen speichern Objektmetadaten 228 ausschließlich für solche Objekte, deren Replikate in der Instanz gespeichert sind (bezeichnet als „lokale Instanzen”). Einige Instanzen speichern Objektmetadaten 228 für alle Objekte, die irgendwo im dezentralen Speichersystem gespeichert sind (bezeichnet als „globale Instanzen”). Die Objektmetadaten 228 werden mit Bezug auf die 3, 4 und 5 in größerem Detail beschrieben.
In einigen Implementierungen speichert jede Instanz Journal-Metadaten 236 für jedes der im dezentralen Speichersystem 200 gespeicherten Journals. Einige Instanzen speichern Journal-Metadaten 236 ausschließlich für Journals, deren Replikate in der Instanz gespeichert sind. Einige Instanzen speichern Journal-Metadaten für alle Journals, die irgendwo im dezentralen Speichersystem gespeichert sind. Die Journal-Metadaten werden unter Bezug auf die 3, 4, 5 und 8 weiter unten in größerem Detail beschrieben.
In den Datenspeichern 224 werden mehrere Typen von Journals gespeichert. Die Mehrheit der Journals sind geschlossene Journals 230. Geschlossene Journals 230 speichern keine weiteren Objektsegmente, ihr Inhalt kann aber gelöscht oder komprimiert werden. In einigen Implementierungen können zwei oder mehr kleine geschlossene Journals 230 für dieselbe Platzierungs-Richtlinie 212 in Form eines einzelnen geschlossenen Ersatz-Journals 230 zusammengeheftet werden. Da Daten innerhalb eines geschlossenen Journals 230 gelöscht und komprimiert werden können, können geschlossene Journals 230 mit der Zeit kleiner werden und sich dadurch für das Zusammenheften qualifizieren.
Zusätzlich zu den geschlossenen Journals 230 kann eine Instanz 102 über die offenen Journals 232 und 234 verfügen. Wie in 2 gezeigt, werden offene Journals entweder als Haupt-Journals 232 oder als Neben-Journals 234 ausgewiesen. Haupt-Journals 232 und Neben-Journals 234 treten in Paaren auf und befinden sich an unterschiedlichen Instanzen. Wie in größerem Detail weiter unten beschrieben empfängt das Haupt-Journal 232 ein Segment 238 zur Speicherung und überträgt eine Kopie des Segments 238 an die Instanz, wo das korrespondierende Journal 234 gespeichert ist.
3 ist ein Blockdiagramm eines Servers 300 gemäß einiger Implementierungen. Der Server 300 beinhaltet typischerweise einen oder mehre Recheneinheiten (CPUs) 302, eine Uhr 303, welche das gegenwärtige Datum und/oder die Zeit vermeldet, einen oder mehrere Netzwerk- oder andere Kommunikationsoberflächen 304, einen Speicher 314 und einen oder mehrere Kommunikationsbusse 312, um diese Komponenten miteinander zu vernetzen. Die Kommunikationsbusse 312 können (manchmal als Chipset bezeichnete) Schaltkreise beinhalten, welche die Kommunikation zwischen Systemkomponenten ermöglichen und regulieren. In einigen Implementierungen ist die Uhr 303 eine lokale Uhr, die periodisch mit einer Serveruhr synchronisiert wird (z. B. einem Quorum-Uhr-Server oder einem beliebigen anderen Uhr-Server an einem Netzwerk etc.). Der Server 300 kann optionalerweise eine Benutzeroberfläche 306 beinhalten, die ein Anzeigegerät 308 und ein Eingabegerät 310 (z. B. Tastatur, Maus, Touchscreen, Keypads etc.) umfasst. Speicher 314 beinhaltet einen hochtourigen Arbeitsspeicher, wie etwa DRAM, SRAM, DDR RAM oder andere Festkörper-Arbeitsspeichergeräte; und kann nichtflüchtigen Speicher beinhalten, wie etwa eine oder mehrere Magnetplatten-Speichergeräte, optische Plattenspeichergeräte, Flash-Speichergeräte oder andere nichtflüchtige Festkörper-Speichergeräte. Speicher 314 kann optionalerweise einen oder mehrere von der/den CPU(s) 302 entfernt ansässige Speichergeräte beinhalten. Speicher 314 oder alternativ das/die nichtflüchtige(n) Speichergerät(e) in Speicher 314 umfassen ein computerlesbares Speichermedium. In einigen Implementierungen speichert Speicher 314 die folgenden Programme, Module und Datenstrukturen, oder eine Teilmenge daraus:

• ein Betriebssystem 316, das Verfahren zur Abwicklung von verschiedenen grundlegenden Systemdienstleistungen und zur Ausführung von Aufgaben, die von der Hardware abhängen;
• ein Kommunikationsmodul 318, das der Verbindung anderer Computer zu Server 300 über eine oder mehrere Kommunikationsoberflächen 304 (verkabelt oder kabellos) dient und eine oder mehrere Kommunikationsnetzwerke wie das Internet, andere Weitverkehrsnetzwerke, lokale Netzwerke, breitbandige Ballungsraumnetzwerke usw.;
• ein optionales Benutzeroberflächenmodul 320, das Befehle vom Anwender über die Eingabegeräte 310 empfängt und Benutzeroberflächenobjekte auf dem Anzeigegerät 308 erzeugt;
• die Konfiguration 204, so wie sie in diesem Dokument beschrieben wird;
• den LAD 206, so wie er in diesem Dokument beschrieben wird;
• Zugriffsdaten 210, so wie sie in diesem Dokument beschrieben werden;
• den globalen Zustand 211, so wie er in diesem Dokument beschrieben wird;
• die Platzierungs-Richtlinie 212, so wie sie in diesem Dokument beschrieben wird;
• Objektmetadaten 228 für die im dezentralen Speichersystem gespeicherten Objekte. Die Objektmetadaten 228 können eine Objekt-ID 330 beinhalten, welche das Objekt innerhalb des dezentralen Speichersystems eindeutig identifiziert. Die Metadaten 228 können den Verfasser 332 des Objekts beinhalten, wobei es sich um einen Namen und/oder eine Kennung einer Person oder Entität (z. B. Email-Adresse) handeln kann. In einigen Implementierungen ist die Kennung einzigartig. Die Metadaten können einen Datumstempel oder einen Zeitstempel 334 beinhalten, die anzeigen, wann das Objekt erzeugt (z. B. in das dezentrale Speichersystem hochgeladen) wurde. Die Metadaten können die Größe 336 des Objekts beinhalten, die typischerweise in Bytes oder zugewiesenen Blöcken gemessen wird. Die Metadaten beinhalten eine zugewiesene Platzierungs-Richtlinie 338, welche individuell oder aufgrund von anderen Kriterien zugewiesen werden kann (z. B. können alle aus den Vereinigten Staaten hochgeladenen Videos dieselbe Platzierungs-Richtlinie 338 zugewiesen bekommen). Die Verwendung der Platzierungs-Richtlinien wird unter Bezug auf die 5–6 und 9A–9C weiter unten in größerem Detail beschrieben. Die Metadaten 228 beinhalten einen Satz Segment-IDs 346, der das Inhaltssegment für jedes Objekt identifiziert. In einigen Implementierungen ist eine Segment-ID definiert als ein Offset innerhalb eines Objekts. Zum Beispiel hat das erste Segment einen Offset von 0. In einigen Implementierungen werden die Offsets in Megabytes angegeben. In einigen Implementierungen handelt es sich bei den Segment-IDs um einzigartige Kennungen (wie eine GUID). In einigen Implementierungen wird jede Segment-ID durch die Verkettung von Objekt-ID mit dem Offset des Segments gebildet. In einigen Implementierungen wird die Segment-ID unter Verwendung eines Inhalts-Hashs oder einer Kurzfassung des Inhalts gebildet. Mit jeder Segment-ID korrespondiert eine zugewiesene Journal-ID 348, welche anzeigt, in welchem Journal das korrespondierende Segment gespeichert ist; und
• die Journal-Metadaten 236 werden für jedes Journal im dezentralen Speichersystem 200 gespeichert. Die Journal-Metadaten 236 beinhalten eine Journal-ID 370 für jedes Journal und einen Satz von Journal-Standorten 372, an denen das Journal gespeichert ist. Die Journal-Standorte 372 bestimmen jede Instanz 102, in der das Journal gespeichert ist und können den Datenspeicher 224 an der Instanz 102 bestimmen, welche das Journal speichert. Die Journal-Metadaten 236 beinhalten außerdem die jedem Journal zugewiesene Platzierungs-Richtlinien-ID 374. Die Platzierungs-Richtlinien-ID 374 identifiziert die dem Journal zugewiesene, einzigartige Platzierungs-Richtlinie 212.

Jedes der oben ausgewiesenen Elemente kann in einem oder mehreren der zuvor genannten Speichergeräte gespeichert sein und korrespondiert mit einem Satz an Instruktionen für die Durchführung einer oben beschriebenen Funktion. Der Satz an Instruktionen kann durch einen oder mehrere Prozessoren (z. B. die CPUs 302) ausgeführt werden. Die oben ausgewiesenen Module oder Programme (d. h. Sätze an Instruktionen) müssen nicht als separate Software-Programme, Prozeduren oder Module implementiert werden, sodass diverse Teilmengen dieser Module in diversen Implementierungen kombiniert oder auf andere Weise angeordnet werden können. In einigen Implementierungen kann der Speicher 314 eine Teilmenge der oben ausgewiesenen Module und Datenstrukturen speichern. Des Weiteren kann der Speicher 314 zusätzliche Module und Datenstrukturen speichern, die weiter oben nicht beschrieben wurden.
Obwohl 3 einen „Server” zeigt, ist 3 eher als funktionale Beschreibung diverser Merkmale beabsichtigt, die in einem Server-Satz 300 vorhanden sein können, denn als strukturelles Schaubild der in diesem Dokument beschriebenen Implementierungen. In der Praxis, und wie von Fachleuten anerkannt werden wird, könnten die getrennt dargestellten Elemente kombiniert und einzelne Elemente getrennt werden. Zum Beispiel könnten einige der separat in 3 abgebildeten Gegenstände auf einzelnen Servern implementiert werden und vereinzelte Gegenstände könnten auf einem oder mehreren Servern implementiert werden. Die tatsächliche Anzahl an Servern und die Art, wie Merkmale zwischen ihnen verteilt sind, variiert von einer Implementierung zur anderen und kann teilweise vom Umfang des Datenverkehrs abhängen, den das System während Spitzenauslastungszeiten und während durchschnittlicher Auslastungszeiten bewältigen muss. In einigen Implementierungen wird eine Teilmenge des LAD 206, der Zugriffsdaten 210, des globalen Zustands 211 und der Platzierungs-Richtlinie 212 auf separaten Servern gespeichert. Zum Beispiel kann sich der LAD 206 auf einem Server (oder einem Server-Satz) befinden, die Zugriffsdaten 210 und der globale Zustand 211 können sich auf einem Statistik-Server 208 (oder einem Satz Statistik-Server 208) befinden und von diesem gepflegt werden und die Platzierungs-Richtlinie 212 kann sich auf einem weiteren Server (oder einem Satz weiterer Server) befinden.
4 ist ein Blockdiagramm eines Instanzen-Servers 400 für eine Instanz 102, gemäß einiger Implementierungen. Der Instanzen-Server 400 beinhaltet typischerweise eine oder mehrere Prozessoreinheiten (CPUs) 402 für die Ausführung von Modulen, eine das gegenwärtige Datum und/oder die Zeit anzeigende Uhr 403, Programme und/oder Instruktionen, die im Speicher 414 gespeichert sind und deshalb Verarbeitungsoperationen ausführen, eine oder mehrere Netzwerk- oder andere Kommunikationsoberflächen 404, Speicher 414 und einen oder mehrere Kommunikationsbusse 412 zur Vernetzung dieser Komponenten. In einigen Implementierungen ist die Uhr 403 eine lokale Uhr, die periodisch mit einer Serveruhr synchronisiert wird (z. B. einem Quorum-Uhr-Server oder einem beliebigen anderen Uhr-Server an einem Netzwerk etc.). In einigen Implementierungen beinhaltet der Instanzen-Server 400 eine Benutzeroberfläche 406, die sich aus einem Anzeigegerät 408 und einem oder mehreren Eingabegeräten 410 zusammensetzt. In einigen Implementierungen beinhaltet Speicher 414 einen hochtourigen Arbeitsspeicher, wie etwa DRAM, SRAM, DDR RAM oder andere Festkörper-Arbeitsspeichergeräte. In einigen Implementierungen beinhaltet der Speicher 414 einen permanenten Speicher, wie ein oder mehrere Magnetdisketten-Speichergeräte, optische Diskettenspeichergeräte, Flash-Speichergeräte oder andere nichtflüchtige (permanente) Festkörper-Speichergeräte. In einigen Implementierungen beinhaltet der Speicher 414 ein oder mehrere Speichergeräte, die vom/von den Prozessoren 402 entfernt gelegen sind. Speicher 414 oder alternativ das/die nichtflüchtige(n) Speichergerät(e) in Speicher 414 umfassen ein computerlesbares Speichermedium. In einigen Implementierungen speichert Speicher 414 oder das computerlesbare Speichermedium des Speichers 414 die folgenden Programme, Module und Datenstrukturen, oder eine Teilmenge daraus:

• ein Betriebssystem 416, das Verfahren zur Abwicklung von verschiedenen grundlegenden Systemdienstleistungen und zur Ausführung von Aufgaben, die von der Hardware abhängen;
• ein Kommunikationsmodul 418, das der Verbindung des Instanzen-Servers 400 zu anderen Instanzen-Servern oder Computer über eine oder mehrere Kommunikationsoberflächen 404 (verkabelt oder kabellos) dient und eine oder mehrere Kommunikationsnetzwerke wie das Internet, andere Weitverkehrsnetzwerke, lokale Netzwerke, breitbandige Ballungsraumnetzwerke usw.;
• ein optionales Benutzeroberflächenmodul 420, das Befehle vom Anwender über die Eingabegeräte 410 empfängt und Benutzeroberflächenobjekte auf dem Anzeigegerät 408 erzeugt;
• ein Replikationsmodul 220 und Replikations-Warteschlangen 222, wie sie in diesem Dokument beschrieben werden;
• Datenspeicher 224 (z. B. dezentrale Datenbanken, Dateisysteme, Bandspeicher, Großtabellen etc.), welche die Objektsegmente 238 in den Journals 230, 232 und 234 speichern, wie unter Bezug auf 3 beschrieben;
• Objektmetadaten 228 und korrespondierende Metadaten-Elemente 330–338, 346 und 348, wie in 3 hinsichtlich Server 300 dargestellt; und
• Journal-Metadaten 236 und korrespondierende Journal-Metadaten-Elemente 370, 372 und 374, wie in 3 hinsichtlich Server 300 dargestellt.

Jedes der oben ausgewiesenen Elemente kann in einem oder mehreren der zuvor genannten Speichergeräte gespeichert sein und korrespondiert mit einem Satz an Instruktionen für die Durchführung der oben beschriebenen Funktion. Der Satz an Instruktionen kann durch einen oder mehrere Prozessoren (z. B. die CPUs 402) ausgeführt werden. Die oben ausgewiesenen Module oder Programme (d. h. Sätze an Instruktionen) müssen nicht als separate Software-Programme, Prozeduren oder Module implementiert werden, sodass diverse Teilmengen dieser Module in diversen Implementierungen kombiniert oder auf andere Weise angeordnet werden können. In einigen Implementierungen kann der Speicher 414 eine Teilmenge der oben ausgewiesenen Module und Datenstrukturen speichern. Des Weiteren kann der Speicher 414 zusätzliche Module und Datenstrukturen speichern, die weiter oben nicht beschrieben wurden.
Obwohl 4 einen „Instanzen-Server” zeigt, ist 4 eher als funktionale Beschreibung diverser Merkmale beabsichtigt, die in einem Server-Satz 400 vorhanden sein können, denn als strukturelles Schaubild der in diesem Dokument beschriebenen Implementierungen. In der Praxis, und wie von Fachleuten anerkannt werden wird, könnten die getrennt dargestellten Elemente kombiniert und einzelne Elemente getrennt werden. Zum Beispiel könnten einige der separat in 4 abgebildeten Gegenstände auf einzelnen Servern implementiert werden und vereinzelte Gegenstände könnten auf einem oder mehreren Servern implementiert werden. Die tatsächliche Anzahl an Servern und die Art, wie Merkmale zwischen ihnen verteilt sind, variiert von einer Implementierung zur anderen und kann teilweise vom Umfang des Datenverkehrs abhängen, den der Server während Spitzenauslastungszeiten und während durchschnittlicher Auslastungszeiten bewältigen muss. Zum Beispiel können sich an einer einzigen Instanz 102 einhundert Instanzen-Server 400 oder gar tausende Instanzen-Server 400 befinden.
In einigen Implementierungen wird, um Clients mit schnelleren Reaktionen zu versorgen und Fehlertoleranz bereitzustellen, jedes Programm oder jeder Prozess, der auf einer Instanz abläuft, zwischen mehreren Computer verteilt. Die Anzahl an jedem Programm oder Prozess zugewiesenen Instanzen-Servern 400 kann variieren und hängt von der Arbeitsbelastung ab.
5 veranschaulicht die Verwendung eines Journals für die Speicherung von Objektsegmenten in Übereinstimmung mit einigen Implementierungen. 5 zeigt einen Datenspeicher 224 sowie einen Teil der Objektmetadaten 228 und einen Teil der Journalmetadaten 236 gemeinsam an der Beispielsinstanz 102. Im Datenspeicher 224 werden viele Journals 230, 232 und 234 gespeichert, von daher ist es nützlich, sie visuell in einem zweidimensionalen Gitter darzustellen. (Natürlich ist die visuelle Darstellung irrelevant für den tatsächlich physischen Speicherort der Journals in einem Datenspeicher.) In der Figur werden die Journals in „Reihen” von Journals unterteilt, wobei jede Reihe mit einer einzelnen Platzierungs-Richtlinie 212 korrespondiert. Zum Beispiel korrespondiert die erste Reihe 502-P1 mit der Platzierungs-Richtlinie P1 (212) und beinhaltet die geschlossenen Journals 230, die offenen Haupt-Journals 232 und die offenen Neben-Journals 234. Allen dieser Journals in der ersten Reihe 502-P1 wird die Platzierungs-Richtlinie P1 zugewiesen. Die zweite Reihe 502-P2 korrespondiert mit der Platzierungs-Richtlinie P2 (212) und die letzte Reihe 502-PN korrespondiert mit der Platzierungs-Richtlinie PN (212). Typischerweise ist die Anzahl an Platzierungs-Richtlinien klein, etwa 10, 20, 50 oder vielleicht 100. Wenn die Anzahl an Platzierungs-Richtlinien wächst, wird die Verwaltung von Objektreplikaten weniger effizient.
Die Journals im Datenspeicher 224 sind in 5 visuell auch in zwei Spalten unterteilt. Die erste Spalte benennt die geschlossenen Journals 230, welche die Mehrheit der Journals umfasst. Die zweite Spalte beinhaltet die offenen Haupt-Journals 232 und die offenen Neben-Journals 234. Wie von den diversen Rechtecken 238 in jedem Journal veranschaulicht, enthält jedes Journal (ob geschlossenes 230, offenes Haupt- 232 oder offenes Neben-Journal 234) die Objektsegmente 238. Die Objektsegmente können verschiedene Größen haben, aber Implementierungen bestimmen typischerweise eine feste Maximalgröße (z. B. 2 Megabytes, 4 Megabytes oder 8 Megabytes). Die Veranschaulichung der Objektsegmente 238 innerhalb eines Journals vermittelt zutreffenderweise die Tatsache, dass ein Journal viele Objektsegmente verschiedener Größen speichert, aber ist ansonsten nicht repräsentativ für die tatsächliche physische Speicherung der Objektsegmente (z. B. gibt es im Allgemeinen keinen ungenutzten Platz zwischen Objektsegmenten, weil jedes neue Objektsegment 238 am Anfang des unbesetzten Platzes angehängt wird).
5 veranschaulicht, dass diverse Kombinationen offener Journals 232 und 234 für jede Platzierungs-Richtlinie möglich sind. Um die unterschiedlichen Journal-Replikate der hiesigen Figuren und Beschreibungen zu bezeichnen, wird manchmal ein dreiteiliges Label verwendet, wie etwa „232.P4.7”. Der erste Teil (z. B. „232”) bezeichnet den Typ Journal (230 = geschlossen, 232 = offenes Haupt-, 234 = offenes Neben-Journal); der zweite Teil (z. B. „P4”) bezeichnet die Platzierungs-Richtlinie für das Journal; und der dritte Teil (z. B. „7”) bezeichnet lediglich eine fortlaufende Nummer für das Journal (z. B. bezeichnet die „7” in „232.P4.7” das siebte offene Journal der Platzierungs-Richtlinie P4).
Wie in 5 veranschaulicht, existiert für die Platzierungs-Richtlinie P1 das einzelne offene Haupt-Journal 232.P1.1 und existieren keine offenen Neben-Journals. Für die Platzierungs-Richtlinie P2 existieren zwei offene Haupt-Journals 232.P2.1 und 232.P2.2.
Für die Platzierungs-Richtlinie PN existieren ein offenes Haupt-Journal 232.PN.1 und ein offenes Neben-Journal 234.PN.1. Wie diese Beispiele veranschaulichen, kann die Anzahl an offenen Haupt-Journals 232 und offener Neben-Journals 234 zwischen Platzierungs-Richtlinien variieren und wird die Anzahl typischerweise für jede Richtlinie 212 aufgrund der erwartbaren Anzahl an neuen Objekten 226 für jede Platzierungs-Richtlinie 212 und des erwünschten Standorts für diese Objekte 226 konfiguriert.
Jede Instanz 102 speichert außerdem sowohl Objektmetadaten 228 und Journalmetadaten 236, wie zuvor unter Bezug auf 3 beschrieben. Für jedes Objekt 226 beinhalten die Objektmetadaten 228 die Objekt-ID 330 (welche das Objekt auf eindeutige Weise identifiziert), weiterhin einen Satz von einer oder mehrerer Segment-IDs 346, welche die Objekt-Segmente 238 des Objekts identifizieren und eine jedem Segment-ID 236 zugewiesene Journal-ID 348. Wenn ein Objekt über mehrere Segmente 238 verfügt, werden die Segmente 238 nicht notwendigerweise alle im selben Journal gespeichert (z. B. zwecks Lastverteilung), daher müssen die Objektmetadaten 228 die jeder Segment-ID 346 zugewiesene Journal-ID 348 nachverfolgen.
Jede Instanz 102 speichert außerdem die Journal-Metadaten 236 für jedes an der Instanz 102 gespeicherte Journal. Die Metadaten 236 beinhalten für jedes Journal eine Journal-ID 370, wie auch einen Satz Standorte 372. In einigen Implementierungen benennt eine Standort-ID eine Instanz; an welcher die Journals gespeichert sind. In einigen Implementierungen benennt eine Standort-ID außerdem einen Datenspeicher an der angegebenen Instanz. In einigen Implementierungen werden eine Instanzenkennung und eine Datenspeicherkennung als separate Attribute für jedes Journal gespeichert. In einigen Implementierungen kann ein Journal in zwei oder mehr Datenspeichern an einer einzelnen Instanz (z. B. einem Dateisystem-Datenspeicher und einem Sicherungsband-Datenspeicher) gespeichert werden. Die Journal-Metadaten 236 beinhalten außerdem eine Platzierungs-Richtlinien-ID 374, welche die mit jedem Journal korrespondierende, eindeutige Platzierungs-Richtlinie 212 festlegt. Jedes Journal speichert ausschließlich solche Objektsegmente 238, deren Platzierungs-Richtlinien 338 mit der Platzierungs-Richtlinie des Journals übereinstimmen.
6 veranschaulicht, wie einige Implementierungen die Speicherung eines neuen Objekts 226 bewerkstelligen. Wie in 6 veranschaulicht, hat jedes neue Objekt sowohl einen Objektinhalt (also das Objekt 226 selbst) als auch eine Objekt-ID 330 (z. B. 58440912) sowie eine zugewiesene Platzierungs-Richtlinie 330 (z. B. P3). Das neue Objekt 226 kann aus vielen verschiedenen Anwendungen 246, etwa einer Online-Email-Anwendung, einer Video-Sharing-Website usw. stammen. Das dezentrale Speichersystem 200 empfängt das neue Objekt 226 und leitet (602) das neue Objekt 226 an eine geeignete Instanz weiter, etwa an die Instanz 102-1. In einigen Implementierungen leitet die Anwendung 246 das neue Objekt 226 an eine bestimmte Instanz 102-1 weiter. Wenn die von der Anwendung 246 ausgewählte Instanz 102-1 nicht ordnungsgemäß ist, leiten einige Implementierungen das Objekt 226 an eine geeignete Instanz weiter (z. B. wenn die Platzierungs-Richtlinie 212 eine Speicherung außerhalb von Europa festlegt und das Objekt 226 an einer Instanz in Europa empfangen wird, kann die Instanz das Objekt 226 an eine andere Instanz weiterleiten).
Obwohl die meisten Objekte von moderater Größe sind (z. B. kleiner als 300 Kilobytes), gibt es einige große Objekte. Einige Implementierungen spalten (604) große Objekte in mehrere Segmente 238. Im Allgemeinen bestimmt jede Implementierung eine Segmentgröße oder hat jede Implementierung einen konfigurierbaren Parameter, um die Segmentgröße festzulegen, die typischerweise in Megabytes angegeben wird (z. B. 2, 4, 8, 16 oder 32 Megabytes). Jedes Objekt, das größer als die Segmentgröße ist, wird in mehrere Segmente gespalten und jedes Objekt, dessen Größe gleich groß oder kleiner als die Segmentgröße ist, besteht aus einem einzelnen Segment. In der Veranschaulichung in 6 existieren drei Segmente C1, C2 und C3. In dieser Veranschaulichung hat jedes der Segmente eine sieben Zeichen lange alphanumerische Segment-ID 346, es sind aber viele alternative Segment-ID-Formate möglich, welche die Segmente innerhalb jedes Objekts eindeutig bezeichnen. In einigen Implementierungen wird eine Segment-ID 346 unter Verwendung eines Inhalts-Hashs oder einer Kurzfassung des Inhalts erzeugt.
In einigen Implementierungen kann es viele Objektduplikate geben (z. B. einen an eine Gruppe von Menschen versandten Email-Anhang, der an viele verschiedene zusätzliche Menschen weitergeleitet wurde), von daher kann die Löschung von Duplikaten für eine effiziente Speicherung nützlich sein. Daher wird in einigen Ausführungsformen der Inhalt eines jeden neuen Segments 238 mit existierenden Objektsegmenten 238 verglichen (606, z. B. unter Verwendung eines Inhalts-Hashs oder einer Kurzfassung des Inhalts) um ausschließlich „neue” Segmente 238 in einem offenen Haupt-Journal zu speichern (606).
Wie in 5 veranschaulicht, ist Segment C2 neu und korrespondiert mit der Platzierungs-Richtlinie P3, deshalb wird C2 in einem mit der Platzierungs-Richtlinie P3 korrespondierenden, offenen Haupt-Journal 232.P3.1 gespeichert. Natürlich ist die Löschung von Duplikaten nur innerhalb des Kontextes einer Platzierungs-Richtlinie sinnvoll. Wenn zwei Segmente identisch, aber zwei unterschiedlichen Platzierungs-Richtlinien zugewiesen sind, werden die zwei Segmente in verschiedenen Journals gespeichert. Anders ausgedrückt, wenn ein neues Segment empfangen wird, wird es nur mit Segmenten derselben Platzierungs-Richtlinie abgeglichen. Ein Segment ist nur dann ein „Duplikat”, wenn es bereits ein identisches gespeichertes Segment derselben Platzierungs-Richtlinie gibt.
Ungeachtet dessen, ob das Objektsegment C2 neu ist, speichert (608) die Instanz 102-1 die Objektmetadaten 228 für das Segment 238. Wie zuvor unter Bezug auf die 3–5 beschrieben, beinhalten die Metadaten 228 die Objekt-ID 330, die Segment-ID 346 und die Journal-ID 348 für das Journal, in dem jedes Segment gespeichert ist. In einigen Implementierungen ist die Segment-ID 346 für ein Objektsegment 238 lediglich der Offset am Anfang eines Segments 238 innerhalb des Objekts. Die in 6 gezeigten Objektmetadaten 228 veranschaulichen außerdem, dass ein Segment für ein Einzelobjekt nicht im selben Journal gespeichert werden muss. Die Segmente C1 und C3 (Segment-IDs C190056 und C098663) befinden sich im selben Journal 232.P3.2 mit der Journal-ID J77298045, wohingegen sich das Segment C2 (Segment-ID C250116) im Journal 232.P3.1 mit der Journal-ID J82117094 befindet.
Das Segment C2 wird zur Speicherung in einem Neben-Journal 234.P3.1 an die Instanz 102-2 übertragen (610) und die Segmente C1 und C3 werden zur Speicherung in einem Neben-Journal 234.P3.2 an die Instanz 102-2 übertragen (612).
6 veranschaulicht außerdem, dass ein Haupt-Journal 232 physisch nicht identisch mit seinem korrespondierenden Neben-Journal sein muss. Zuerst sehen wir, dass die Segmente C1 und C3 in einer Reihenfolge im Haupt-Journal 232.P3.2 gespeichert sind, wohingegen diese Segmente im Neben-Journal 234.P3.2 in der umgekehrten Reihenfolge gespeichert sind. Während ein Journal offen ist, können die individuellen Segmente 238 unabhängig voneinander repliziert werden, unterschiedliche Netzwerkpfade beschreiten, oder von unterschiedlichen Prozessoren 402 verarbeitet werden, sodass es keine Garantie gibt, dass sie in derselben Reihenfolge in das Neben-Journal 234.P3.2 geladen werden. Die Tatsache, dass es unterschiedliche Reihenfolgen geben kann, wird, wie weiter unten mit Bezug auf 7 beschrieben, durch den Segmentindex gehandhabt. Zusätzlich zeigt das Haupt-Journal 232.P3.1 das Vorhandensein eines Abfall-„segments” 620 an, das in der Figur als „G” (garbage) bezeichnet wird. Manchmal kann es während eines Uploads einen Fehler oder Aussetzer geben, der Platz beansprucht. Zum Beispiel wird während eines Uploads möglicherweise der Platz für ein Objekt zugewiesen, aber das Segment tatsächlich nicht angehängt. Die Software versucht den Upload aufs Neue, was neuen Platz für das Segment zuweist. Dies kann Löcher oder Abfall innerhalb eines Journals 232 belassen. In diesem Fall wird der Abfall 620 nicht in das Neben-Journal übertragen, sodass sich das Haupt-Journal physisch vom Neben-Journal unterscheidet.
7 veranschaulicht die Struktur eines offenen Journals in Übereinstimmung mit einigen Implementierungen. Obwohl 7 ein offenes Haupt-Journal 232 beschreibt, wäre die Struktur oder ein offenes Neben-Journal 234 ähnlich oder identisch. Ein Journal 232 verfügt über einen Header 702 und einen Block an Speicherplatz 714. Der Speicherplatz 714 beinhaltet einen gefüllten Teil 710, der die Objektsegmente 238 bereits speichert und einen leeren Teil 712, der gegenwärtig ungenutzt ist. Diese Deskriptoren sind aus einigen Gründen nicht vollständig akkurat. Erstens kann der „gefüllte” Platz 710 die Abfallteile 620 beinhalten, die keinen nützlichen Inhalt haben. Zweitens wird der ungenutzte Platz nicht notwendigerweise zur selben Zeit in Gänze zugewiesen. Einige Implementierungen weisen den gesamten Platz für das Journal zu einer Zeit zu und schließen das Journal, wenn es voll ist (was potentiell eine kleine Menge ungenutzten Platzes am Ende übrig lässt). In anderen Implementierungen aber werden, wenn notwendig, Blöcke zusätzlichen Platzes zugewiesen, bis das Journal ein bestimmtes Größenlimit erreicht, oder eine bestimmte Menge Zeit (z. B. ein Tag) vergangen ist.
Der Header 702 des Journals enthält wichtige interne Informationen über das Journal 232. Der Header 702 beinhaltet ein Feld 704, das bestimmt, wo der ungenutzte Platz 712 des Journals beginnt. Jedes Mal, dass ein neues Segment 238 ans Ende eines gefüllten Platzes 710 angehängt wird, erhöht sich der Offset 704 um die Größe des Segments 238, sodass das Journal 232 darauf vorbereitet ist, das nächste Segment abzuspeichern.
Der Header 702 beinhaltet außerdem einen Segmentindex 706. Der Segmentindex 706 für ein Journal 232 bestimmt sowohl, wo sich jedes Segment 238 innerhalb des Journals 232 befindet, als auch seine Größe, was ein rasches Auslesen der Segmentdaten (ob aus nichtflüchtigem Speicher oder dem Cache) ermöglicht. Der Schlüssel für das Segmentindex 706 ist die Segment-ID 346, welche das Segment eindeutig identifiziert. Beachten Sie, dass sich mehrere unterschiedliche Objekt-IDs 330 auf dieselben physischen Segmente beziehen können. Um einen übergroßen Segmentindex 704 mit vielen Einträgen, die auf dasselbe Objektsegment 238 verweisen, zu vermeiden, verwenden Implementierungen typischerweise eine einzelne Segment-ID, um sich auf denselben physischen Inhalt zu beziehen. Zum Beispiel kann es sich bei der Segment-ID 346 um einen Inhalts-Hash oder um eine Kurzfassung eines Inhalts (oder um eine Kombination derselben) handeln. Für jede Segment-ID 346 bestimmt der Segmentindex 720 ein Offset 720 und eine Größe 722 für das Segment 238 innerhalb des Speicherplatzes 714. Der Offset 720 kann entweder als Offset am Anfang des Journals 232 oder als Offset am Anfang des gefüllten Platzes 710 festgelegt werden. In einigen Implementierungen enthält der Segmentindex zusätzliche Informationen wie etwa einen Löschmarker, der später verwendet wird, wenn die Segmente gelöscht wurden und der gefüllte Platz 710 komprimiert wurde.
Der Header 702 kann sowohl weitere Journaldaten 708 als auch Adressenimplementierungsdetails enthalten. Zum Beispiel können die weiteren Journaldaten 708 den Offset vom Anfang des Journals zum Anfang des gefüllten Speicherplatzes 714 (d. h. der Größe des Headers) bestimmen. In einigen Implementierungen beinhalten die anderen Journaldaten einen „Lebenszeit”-Parameter für Journals, die dazu bestimmt sind, eine kurze Lebensspanne zu haben.
Obwohl die Struktur des Journals in 7 die eines offenen Haupt-Journals 232 ist, findet dieselbe grundlegende Struktur Anwendung auf offene Neben-Journals 234 und auch auf die geschlossenen Journals 230.
8 veranschaulicht, was mit den Objektmetadaten 228 und den Journalmetadaten 236 passiert, wenn ein Journal von einer Instanz in die andere repliziert wird, in Übereinstimmung mit einigen Implementierungen. In dieser Veranschaulichung wird das geschlossene Journal 230 mit der Journal-ID J82117094 (820) von der Instanz 102-1 (mit Instanz-ID = 723) in die Instanz 102-4 (mit der Instanz-ID 428) bewegt. Weil das Journal 230 selbst als Einheit repliziert wird, wird der gesamte Inhalt exakt repliziert. Zum Beispiel befindet sich Segment C8 (mit der Segment-ID C408335) an exakt derselben Position innerhalb des Journals. Natürlich handhaben die Instanzen 102-1 und 102-4 nach der Replizierung unabhängig voneinander Löschungen und Komprimierung, sodass ihre physischen Strukturen einander nach der Replizierung nicht unbedingt entsprechen.
8 zeigt außerdem einen Teil der Objektmetadaten 228 und Journal-Metadaten 236, sowohl vor als auch nach der Replizierung 820. Wie angegeben, bleiben die Aufzeichnungen 802–814 in den Objektmetadaten 228 durch die Replizierung 820 unverändert. Jedes Objekt 226 verfügt über dieselben Segmente 238 und die Segmente 238 werden im selben Journal 230 gespeichert. Zum Beispiel bleibt das Segment mit der Segment-ID C408335 (in Reihe 804) unverändert. Auf der anderen Seite verändern sich die Journal-Metadaten 236 für das Journal 230 mit der Journal-ID J82117094 (370-1) durchaus. Der Satz von Journalstandorten 372 verändert sich von 372-1(A) zu 372-1(B), was den neuen Standort 428 (für die Instanz 102-4) beinhaltet.
9A–9C veranschaulichen ein Verfahren 900 der Verwaltung (902) der Platzierung von Objektreplikaten in einem dezentralen Speichersystem 200 gemäß einiger Implementierungen. Das Verfahren wird in einer ersten Instanz 102 des dezentralen Speichersystems durchgeführt (904), die über einen oder mehrere Prozessoren und einen Speicher verfügt. Der Speicher speichert (906) eine Vielzahl von Objekten. Der Speicher speichert (908) außerdem ein oder mehrere Programme für die Ausführung durch einen oder mehrere Prozessoren. In einigen Implementierungen wird das Verfahren 900 insgesamt oder teilweise durch den Standortzuweisungs-Daemon 206 ausgeführt. In einigen Implementierungen verfügt (910) das dezentrale Speichersystem über eine Vielzahl von Instanzen. In einigen Implementierungen befindet (910) sich wenigstens eine Teilmenge der Instanzen an verschiedenen geografischen Standorten. In einigen Implementierungen korrespondiert jede Instanz mit einem Datenzentrum. In einigen Implementierungen umfasst jedes Datenzentrum eine oder mehrere Instanzen.
In der ersten Instanz werden eine oder mehrere Journals 232 für die Speicherung von Objektsegmenten geöffnet (912). Jedem Journal wird eine einzelne jeweilige Platzierungs-Richtlinie 212 zugewiesen (914). In einigen Implementierungen bestimmt (926) jede Platzierungs-Richtlinie eine Zielanzahl an Objektreplikaten und einen Zielsatz an Standorten für die Objektreplikate. In einigen Implementierungen kann eine Platzierungs-Richtlinie 212 festlegen, welche Typen von Datenspeichern 224 in einigen der Instanzen verwendet werden sollen (z. B. auf Festplatte oder auf Band). In einigen Implementierungen beinhaltet (918) das dezentrale Speichersystem 200 die Objektmetadaten 228, die bestimmen, in welchem Journal jedes Objektsegment 238 gespeichert wird. Dies wurde zuvor unter Bezug auf die 3–5 beschrieben. In einigen Implementierungen beinhaltet (920) jedes jeweilige Journal einen Segmentindex 706, der den Standort jedes im jeweiligen Journal gespeicherten Objekts bestimmt. Dies wurde in größerem Detail in 7 beschrieben. Insbesondere wird der Standort jedes Segments in einem Journal im Verhältnis zum Journal selbst identifiziert, sodass der Segmentindex 706 ungeachtet dessen richtig ist, wo das Journal gespeichert ist. Zum Beispiel kann durch die Definierung der Segmentstandorte innerhalb eines Journals als Offsets auf die Segmente durch relative Adressierung zugegriffen werden.
Die offenbarten Implementierungen beinhalten (922) typischerweise die Journalmetadaten 236, welche die Standorte 372 bestimmen, an denen jedes Journal gespeichert wird. Dies wurde zuvor in den 3–5 und 8 beschrieben.
Die Verteilung der offenen Haupt-Journals 232 und der offenen Neben-Journal 234 hängt von vielen Faktoren ab, einschließlich der verfügbaren Instanzen 102, der Platzierungs-Richtlinie 212, der erwartbaren Verteilung neuer Objekte 226 mit den Platzierungs-Richtlinien 212, des Orts von dem aus neue Objekte hochgeladen werden (z. B. Europa, Nordamerika, Asien), der Ressourcenverarbeitung an jeder der verfügbaren Instanzen 102 und der Netzwerkbandbreite zwischen den diversen Instanzen. Zum Beispiel werden, wenn viele Objekte mit einer bestimmten Platzierungs-Richtlinie an einer bestimmten Instanz hochgeladen werden, mehrere Journals für dieselbe Platzierungs-Richtlinie an dieser Instanz geöffnet (924). In einigen Szenarien können 5, 10 oder mehr offene Journals für dieselbe Platzierungs-Richtlinie 212 an einer einzelnen Instanz 102 existieren, wenn dies für die Lastverteilung erforderlich ist.
Wie zuvor unter Bezug auf die 5 und 6 beschrieben, senden (916) einige Implementierungen eine Nachricht an eine dritte Instanz des dezentralen Speichersystems 200, die sie anweist, die mit den an der ersten Instanz geöffneten Journals korrespondierenden Journals zu öffnen. In diesem Szenario werden die an der ersten Instanz geöffneten Journals 232 als Haupt-Journals und die an der dritten Instanz geöffneten Journals 234 als Neben-Journals bezeichnet. (Natürlich könnte die erste Instanz auch über Neben-Journals und könnte die dritte Instanz über Haupt-Journals verfügen.)
An der ersten Instanz 102 wird ein erstes Objekt 226 empfangen (928), das mindestens ein erstes Objektsegment umfasst (928). Dies wurde oben unter Bezug auf die 6 beschrieben. Das erste Objekt 226 wird einer Erstplatzierungs-Richtlinie 212 zugewiesen, wodurch alle Objektsegmente 238, die das Objekt 226 umfasst, der Erstplatzierungs-Richtlinie 212 zugewiesen werden. Das erste Objektsegment 238 wird in einem ersten Journal 232 gespeichert (930), dessen zugewiesene Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie 212 übereinstimmt. Das erste Journal 232 speichert ausschließlich (932) Objektsegmente für Objekte, deren Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie übereinstimmt. In einigen Implementierungen wird jedes im ersten Journal 232 gespeicherte Objektsegment 238 an die dritte Instanz übertragen (934), um dort in einem dritten Journals 234 gespeichert zu werden.
Wenn das empfangene Objekt größer als die Segmentgröße ist, wird das Objekt in mehrere Segmente 238 gespalten. In diesem Fall umfasst (936) das erste Objekt 226 zwei oder mehr Objektsegmente. Typischerweise unterscheidet sich (936) das zweite Objektsegment vom ersten Objektsegment. (Das Vorhandensein zweier identischer Segmente innerhalb eines einzigen Objekts ist selten, kann aber vorkommen, zum Beispiel wenn ein Objekt einen sehr großen Anteil leeren Platzes hatte.) In bestimmten Fällen wird das zweite Objektsegment in einem zweiten, vom ersten Journal unterschiedlichen Journal 232 gespeichert (938), dessen zugewiesene Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie übereinstimmt. Das zweite Journal speichert ausschließlich (938) Objektsegmente für Objekte, deren Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie übereinstimmt. Auf diese Weise könnte ein Objekt, das viele Segmente umfasst, die Segmente über viele verschiedene Journals verteilt haben.
Dieser Vorgang des Empfangens von Objekten 226 und der Speicherung der Segmente 238 im ersten Journal 232 wird für eine Vielzahl von Objekten 226, deren zugewiesene Platzierungs-Richtlinie 338 mit der Erstplatzierungs-Richtlinie 212 übereinstimmt, solange wiederholt (940), bis dass eine erste Beendigungsbedingung eintrifft. In einigen Implementierungen tritt die erste Beendigungsbedingung ein, wenn (942) die Größe des ersten Journals einen zuvor festgelegten Grenzwert überschreitet. In einigen Implementierungen tritt die erste Beendigungsbedingung ein, wenn (944) das erste Journal für eine zuvor festgelegte Zeitspanne offen gewesen ist. Einige Implementierungen verbinden Größe und Zeit auf verschiedene Arten und Weisen. Zum Beispiel bestimmen einige Implementierungen sowohl eine Zeitspanne als auch ein Größenlimit und die Beendigungsbedingung ist diejenige, welche als erstes eintritt.
Nachdem die erste Beendigungsbedingung eintritt, wird das erste Journal geschlossen (946), wodurch die Speicherung weiterer Objektsegmente im ersten Journal 232 verhindert wird. Im Allgemeinen versichern sich Implementierungen, dass die anderen Journals 232 derselben Platzierungs-Richtlinie weiterhin offen sind (oder ein neues geöffnet wird) bevor sie das erste Journal schließen. Da Objekte zu jeder Zeit ankommen können, ist es wichtig, offene Journals für die Speicherung bereit zu halten. Wenn ein korrespondierendes Neben-Journal 234 an einer anderen Instanz existiert, sendet (948) die erste Instanz eine Nachricht an die andere Instanz, die sie anweist, das korrespondierende Neben-Journal zu schließen, sobald die erste Beendigungsbedingung eintritt.
Nachdem das erste Journal 232 geschlossen wurde, unterliegt das Journal seiner Platzierungs-Richtlinie. Die Erfüllung der Platzierungs-Richtlinie 212 kann das Bewegen eines Journalreplikats, die Erstellung einer neuen Kopie eines Journalreplikats, oder die Löschung eines Journalreplikats erfordern. In bestimmten Fällen wird das erste Journal 232 in einer zweiten Instanz 102 des dezentralen Speichersystems 200 in Übereinstimmung mit der Platzierungs-Richtlinie 212 repliziert (950). (In anderen Fällen wird ein Replikat des ersten Journals gelöscht.) In Implementierungen, die über offene Haupt- und Neben-Journals 232 und 234 verfügen, werden, sobald sie geschlossen wurden, zwei einander entsprechende geschlossene Journals 230 existieren. Folglich könnte jedes der Replikate als Ausgangspunkt für die Replizierung 950 verwendet werden. Während des Replizierungsvorgangs 950 (d. h. als Teil der Transaktion) werden die Journalmetadaten 236 für das erste Journal aktualisiert (952), um anzuzeigen, dass es an der zweiten Instanz eine Kopie des Journals gibt. Dies wurde oben unter Bezug auf die 8 beschrieben.
Nachdem ein Journal 230 geschlossen wurde, können die Objektsegmente 238 gelöscht werden. Zum Beispiel kann mit einem Objekt ein Email-Anhang korrespondieren. Wenn der Empfänger einer Email die Email löscht, kann der für den Anhang verwendete Speicher gelöscht werden. Nach einem gewissen Zeitraum entstehen durch die Löschungen Löcher innerhalb jedes Journals und ist es daher nützlich, das Journal zu komprimieren, um verschwendeten Platz zu entfernen. Dies ist vergleichbar mit der Fragmentierung flüchtigen Speichers und mit dem Defragmentierungsprozess, um ungenutzten Platz in größeren, fortlaufenden Blöcken zu verdichten.
Da ein gespeichertes Objektsegment mit vielen (z. B. hunderten, tausenden oder Millionen) unterschiedlichen Objekten korrespondieren kann, kann ein Objektsegment in einem Journal nur dann gelöscht werden, wenn keine Verweise darauf mehr existieren. Folglich ermittelt (956) der Prozess 900, sobald ein erstes geschlossenes Journal 230 ausgewählt (954) wurde, ein oder mehrere im ersten geschlossenen Journal 230 gespeicherte Objektsegmente, bezüglich derer in den Objektmetadaten 228 keine Verweise existieren. Bezüglich dieser ermittelten Segmente 238 wird der Segmentindex 706 aktualisiert (958), um die korrespondierenden Aufzeichnungen zu entfernen. In einigen Implementierungen wird der zuvor den ermittelten Objektsegmenten zugewiesene Platz überschrieben (z. B. wird jedes Byte auf ASCII 0 gesetzt), während in anderen Implementierungen der Platz einfach nicht länger referenziert wird. In einigen Implementierungen wird der freigegebene Speicherplatz als Teil der anderen Journaldaten 708 nachgehalten. Zum Beispiel pflegen einige Implementierungen eine Liste freigegebenen Speicherplatzes (z. B. Offset und Größe) und halten den frei gewordenen Platz als verbundene Liste nach.
In einigen Implementierungen läuft periodisch ein Abfallsammlungsalgorithmus, um jedes der geschlossenen Journals zu komprimieren (960). Der Komprimierungsvorgang verdichtet (960) die gespeicherten Objektsegmente in einem fortlaufenden Block, was die Größe des Journals 230 verringert. Mit der Zeit können die Journals 230 dadurch klein werden, dass mehr und mehr Objektsegmente gelöscht werden. Die Verwaltung vieler kleiner Journals bedeutet einen Mehraufwand vergleichbar der Verwaltung individueller Objekte, wodurch der Nutzen eines Journalspeichers abnimmt. Um mit dieser Problematik umzugehen heften (962) einige Implementierungen zwei oder mehr geschlossene Journals zusammen, um ein einziges Ersatzjournal zu bilden, und aktualisieren (962) die Objektmetadaten 228, um anzuzeigen, dass die zuvor in den zwei oder mehr Journals gespeicherten Objektsegmente nun im Ersatzjournal gespeichert werden. Da ein Zusammenheftungsvorgang der Bildung eines vollkommen neuen Journals und der Aktualisierung der Metadaten für alle involvierten Objekte bedarf, wird die Zusammenheftung üblicherweise auf ein Szenario beschränkt, in dem die Journals relativ klein geworden sind.
10A und 10B veranschaulichen zwei Implementierungen für die Speicherung von Objekten und zugewiesener Metadaten in einem dezentralen Speichersystem. Die in 10A veranschaulichte Implementierung ist vollständig hierarchisch: Jedes Objekt wird in ein oder mehrere Segmente gespalten und jedes Segment wird in einen oder mehrere Blöcke gespalten. Beachten Sie, dass die Struktur sogar dann hierarchisch ist, wenn nur ein Segment oder nur ein Block existiert. Auf der anderen Seite ist die in 10B veranschaulichte Implementierung nur teilweise hierarchisch. In dieser Implementierung handelt es sich bei einigen Segmenten um „Super-Segmente”, was sich auf Listen von Blöcken bezieht. Zum Beispiel kann ein Super-Segment über eine Blockliste von 100 Blöcken, 1000 Blöcken oder sogar mehr verfügen. Ein Segment, das kein Super-Segment ist, ist lediglich ein Block. Beziehungsweise bezieht sich die Segmentkennung vielmehr auf einen tatsächlichen Speicher von Objektdaten, anstatt auf eine Blockliste. Dieser Hybrid-Ansatz kann in einem dezentralen Speichersystem nützlich sein, welches sowohl kleine Objekte (für die keine Hierarchie nötig ist) als auch sehr große Objekte umfasst, wo eine Speicherhierarchie sehr viel effizienter ist.
Die globalen Metadaten 1002 beinhalten die Objektmetadaten 228 und die Journalmetadaten 236, wie in den 2–4 veranschaulicht. In einigen Implementierungen wird jeder Segment-ID 346 ein Entschlüsselungsschlüssel 1040 zugewiesen, der zur Entschlüsselung der Daten für das Segment verwendet wird. In diesen Implementierungen würde derselbe Entschlüsselungsschlüssel auf alle Blöcke in einem Segment Anwendung auf solche Segmente finden, die in mehrere Blöcke gespalten werden. Jedes Segment hat seinen eigenen Entschlüsselungsschlüssel 1040, der im Endeffekt einzigartig ist. Einige Implementierungen garantieren die Einzigartigkeit, wenn neue Schlüssel generiert werden, aber einige Implementierungen generieren Schlüssel zufällig, was die Wiederholung von Schlüsseln höchst unwahrscheinlich macht. Der Entschlüsselungsschlüssel 1040 korrespondiert mit einem Verschlüsselungsschlüssel, der verwendet wird, um neue Objekte während der Speicherung zu verschlüsseln. Weil der Entschlüsselungsschlüssel 1040 benötigt wird, um auf jedes neue Objektsegment zuzugreifen, kann die Löschung des Entschlüsselungsschlüssels als „weiche” Löschung eines Objektsegments verwendet werden. Wenn der Entschlüsselungsschlüssel entfernt wurde, handelt es sich bei dem verschlüsselten Speicher um „Abfall” und kann auf die tatsächlichen Daten nicht zugegriffen werden. Dies kann dem Abfallsammlungsalgorithmus mehr Zeit zwischen Komprimierungen gewähren und der Abfallsammlungsvorgang kann, wenn er abläuft, größere Mengen an Speicherplatz zurückgewinnen.
Außerdem in 10A veranschaulicht werden das Journal 232 (welches als offen angezeigt wird) und die damit korrespondierenden lokalen Metadaten 1004. In einigen Implementierungen werden die lokalen Metadaten 1004 für das Journal 232 im Journal selbst als Teil des Headers 702 gespeichert. In anderen Implementierungen werden die lokalen Metadaten 1004 für ein Journal als eine separate Datei (oder in einer Datenbank etc.) gespeichert und einem Journal zugewiesen. Die Struktur eines Journals 232 für eine nichthierarchische Speicherung wurde oben unter Bezug auf 7 veranschaulicht. In dieser Implementierung ist, anstelle der Speicherung von Segmenten, die Grundeinheit der Speicherung der Block 1016, wie etwa die Blöcke 1016-1, 1016-2, ..., 1016-N. Jede Implementierungen bestimmt typischerweise eine maximale Blockgröße, wie etwa 2 Megabytes, 4 Megabytes, 8 Megabytes oder 16 Megabytes.
Wie oben bemerkt, können die lokalen Metadaten 1004 im Header 702 des Journals 232 oder separat davon gespeichert werden. Für jede Segmentkennung 346 existiert eine korrespondierende Blockliste 1006 (typischerweise eine einzigartige Blockliste), die einen oder mehrere Blockkennungen 1008 umfasst. Für ein kleines Segment kann die Blockliste 1006 eine einzelne Blockkennung 1008 enthalten. Die lokalen Metadaten 1004 beinhalten außerdem einen Blockindex 1010, der festlegt, wo sich jeder Block innerhalb des Journals 232 aufhält. In einigen Implementierungen wird der Standort eines Blocks durch einen Offset und eine Größe bestimmt. Der Block-Offset 1012 ist in einigen Implementierungen der Offset am Anfang des Speicherplatzes 714 oder der Offset am Anfang der Journaldatei 232. Typischerweise wird die Blockgröße 1014 in Bytes angegeben, andere Implementierungen verwenden aber alternative Grundeinheiten für die Größe (z. B. 2 Bytes, 4 Bytes oder 8 Bytes). Ein Aspekt der lokalen Metadaten ist, dass sie sich nicht verändern, wenn ein Journal bewegt oder an einer anderen Instanz repliziert wird: Die Blockliste 1006 für ein Segment bleibt dieselbe, die Block-IDs 1008 bleiben dieselben, die Block-Offsets 1012 innerhalb des Journals bleiben dieselben und die Blockgröße bleibt dieselbe.
10B ist ähnlich der 10A, veranschaulicht aber eine teilweise hierarchische Struktur. In der teilweise hierarchischen Struktur von 10B beinhalten die globalen Metadaten 1002 ein „Super-Segment”-Feld 1020, das anzeigt, ob es sich bei einem Segment um einen gewöhnlichen Block handelt oder es sich auf eine Blockliste bezieht (d. h., dass es sich um ein Super-Segment handelt). In einigen Implementierungen sind die meisten Objekte klein und bestehen aus einem einzelnen Segment. In diesem Fall identifiziert die Segment-ID 346 einen Block unmittelbar im Segment-/Blockindex 1024. Das heißt, dass es sich bei der Segment-ID 346 um eine Segment-/Block-ID 1026 handelt. Somit gilt für Segmente, bei denen es sich nicht um Super-Segmente handelt, dass die Segment-ID 346 verwendet werden kann, um die entsprechende Aufzeichnung im Segment-/Blockindex 1024 nachzuschlagen und so das Offset 1028 und die Größe 1030 für den korrespondierenden Block 1016 im Journal 232 zu finden.
Im Falle von Super-Segmenten handelt es sich bei der Segment-ID 346 um eine (Super-)Segment-ID 1022, welche in den lokalen Metadaten 1004 gesucht werden kann. Mit der Super-Segment-ID 1022 korrespondiert eine Blockliste 1006, welche einen Satz an Block-IDs 1008 umfasst. In diesem Fall kann jede der Block-IDs im Segment-/Blockindex 1024 nachgeschlagen werden, um den Offset 1028 und die Größe 1030 für jede der Block-IDs 1026 in der Blockliste 1006 mit der Super-Segment-ID 1022 zu ermitteln. Wie zuvor identifizieren die Offsets 1028 und die Größe 1030 den Standort des tatsächlichen Blockspeichers im Speicherplatz 714 des Journals 232. Super-Segmente haben somit ein zusätzliches Hierarchielevel, verringern aber die Menge an in den globalen Metadaten 1002 gespeicherten Segmentmetadaten. Dies macht es einfacher und effizienter, ein Bruchstück von einer Instanz an eine andere zu bewegen.
11A–11D veranschaulichen ein Verfahren 1100 der Verwaltung (1102) der Platzierung von Objektreplikaten in einem dezentralen Speichersystem 200 gemäß einiger Implementierungen. Das Verfahren wird in einer ersten Instanz 102 des dezentralen Speichersystems durchgeführt (1104), die über einen oder mehrere Prozessoren und einen Speicher verfügt. Der Speicher speichert (1106) ein oder mehrere Programme für die Ausführung durch einen oder mehrere Prozessoren. In einigen Implementierungen wird das Verfahren 1100 insgesamt oder teilweise durch den Standortzuweisungs-Daemon 206 ausgeführt. In einigen Implementierungen verfügt (1108) das dezentrale Speichersystem über eine Vielzahl von Instanzen. In einigen Implementierungen befindet (1108) sich wenigstens eine Teilmenge der Instanzen an verschiedenen geografischen Standorten. In einigen Implementierungen korrespondiert jede Instanz mit einem Datenzentrum. In einigen Implementierungen umfasst jedes Datenzentrum eine oder mehrere Instanzen.
In der ersten Instanz werden eine oder mehrere Journals 232 für die Speicherung von Objektsegmenten geöffnet (1110). Jedem Journal wird eine einzelne jeweilige Platzierungs-Richtlinie 212 zugewiesen (1112). In einigen Implementierungen bestimmt (1122) jede Platzierungs-Richtlinie eine Zielanzahl an Objektreplikaten und einen Zielsatz an Standorten für die Objektreplikate. In einigen Implementierungen kann eine Platzierungs-Richtlinie 212 festlegen, welche Typen von Datenspeichern 224 in einigen der Instanzen verwendet werden sollen (z. B. auf Festplatte oder auf Band). In einigen Implementierungen beinhaltet (1114) das dezentrale Speichersystem 200 die Objektmetadaten 228 (Teil der globalen Metadaten 1002), die bestimmen, in welchem Journal jedes Objektsegment 238 gespeichert wird. Dies wurde zuvor unter Bezug auf die 3–5, 10A und 10B beschrieben. In einigen Implementierungen beinhaltet (1116) jedes jeweilige Journal einen Blockindex 1010 oder 1026, der den Standort jedes im jeweiligen Journal gespeicherten Blocks bestimmt. Dies wurde in größerem Detail in den 7 (nicht-hierarchisch), 10A und 10B beschrieben. Insbesondere wird der Standort jedes Blocks 1016 in einem Journal 232 im Verhältnis zum Journal selbst identifiziert, sodass der Blockindex 1010 oder 1026 ungeachtet dessen richtig ist, wo das Journal 232 gespeichert ist. Zum Beispiel kann durch die Definierung der Blockstandorte 1016 innerhalb eines Journals 232 als Offsets auf die Blöcke 1016 durch relative Adressierung zugegriffen werden.
Die offenbarten Implementierungen beinhalten (1118) typischerweise die Journalmetadaten 236 (Teil der globalen Metadaten 1002), welche die Standorte 372 bestimmen, an denen jedes Journal gespeichert wird. Dies wurde zuvor in den 3–5 und 8 beschrieben.
Die Verteilung der offenen Haupt-Journals 232 und der offenen Neben-Journal 234 hängt von vielen Faktoren ab, einschließlich der verfügbaren Instanzen 102, der Platzierungs-Richtlinie 212, der erwartbaren Verteilung neuer Objekte 226 mit den Platzierungs-Richtlinien 212, des Orts von dem aus neue Objekte hochgeladen werden (z. B. Europa, Nordamerika, Asien), der Ressourcenverarbeitung an jeder der verfügbaren Instanzen 102 und der Netzwerkbandbreite zwischen den diversen Instanzen. Zum Beispiel werden, wenn viele Objekte mit einer bestimmten Platzierungs-Richtlinie an einer bestimmten Instanz hochgeladen werden, mehrere Journals für dieselbe Platzierungs-Richtlinie an dieser Instanz geöffnet (1120). In einigen Szenarien können 5, 10 oder mehr offene Journals für dieselbe Platzierungs-Richtlinie 212 an einer einzelnen Instanz 102 existieren, wenn dies für die Lastverteilung erforderlich ist.
An der ersten Instanz 102 wird ein erstes Objekt 226 empfangen (1124), das mindestens ein erstes Objektsegment umfasst (1124). Dies wurde oben unter Bezug auf die 6 beschrieben. Das erste Objekt 226 wird einer Erstplatzierungs-Richtlinie 212 zugewiesen (1124), wodurch alle Objektsegmente 238, die das Objekt 226 umfassen, der Erstplatzierungs-Richtlinie 212 zugewiesen werden. Das erste Objektsegment umfasst (1126) eine erste Vielzahl von Blöcken, wie es oben unter Bezug auf die 10A und 10B beschrieben wurde. In einigen Implementierungen empfängt (1124) der Prozess 1100 das bereits in Segmente und Blöcke unterteilte Objekt 238. Zum Beispiel kann die Zerspaltung durch das Client-Gerät durchgeführt werden, welches das Objekt hochlädt. In anderen Implementierungen empfängt der Prozess 1100 ein Objekt als Stream und spaltet das Objekt gemäß gespeicherter Kriterien (z. B. Block- und Segment-Zielgröße, verfügbare offene Journals, verfügbare Instanzen, verfügbare Bandbreite etc.) in Segmente und Blöcke auf. In einigen Implementierungen erfolgt eine dynamische Zuweisung von Segmenten bereits während noch Objektdaten empfangen werden, wohingegen andere Implementierungen ein Objekt erst dann in Segmente und Blöcke aufspalten, nachdem das gesamte Objekt empfangen wurde.
Die Hierarchie von Segmenten und Blöcken kann auf verschiedene Arten und Weisen gebildet werden und basiert auf verschiedenen Faktoren, wie etwa der Größe des Objekts. In einigen Implementierungen wird die Hierarchie dynamisch während des Upload-Vorgangs gebildet. Zum Beispiel wird ein erstes Objektsegment erzeugt und der Datenstrom wird dann in Blöcke aufgespalten, die dem ersten Objektsegment zugewiesen werden, bis dass dem Segment eine Grenzwertanzahl an Blöcken zugewiesen wurde. Zu diesem Zeitpunkt wird ein zweites Segment erzeugt und die Blöcke werden dem zweiten Segment hinzugefügt. In einer anderen Implementierung wird der Datenstrom zuerst als Speicherblöcke gespeichert und, wenn es keine weiteren Blöcke mehr gibt, werden die Blöcke in Segmenten gruppiert.
In einigen Implementierungen umfasst (1128) jedes Objektsegment 238 einen oder mehrere Blöcke. Dies wurde oben unter Bezug auf die 10A veranschaulicht. In einigen Implementierungen beinhalten (1130) die globalen Metadaten 1002 ein Feld 1020, das bestimmt, ob jedes Objektsegment 238 ein Block oder eine Blockliste ist. Dies ist oben in 10B veranschaulicht. In einigen Instanzen ist (1132) das erste Objektsegment eine Blockliste (d. h. ein Super-Segment), wohingegen es sich bei dem zweiten Segment (1132) um einen gewöhnlichen Block (kein Super-Segment) handelt.
Die erste Vielzahl von Blöcken 1016 wird in einem ersten Journal 232 gespeichert (1134), dessen zugewiesene Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie 212 übereinstimmt. Das erste Journal 232 speichert ausschließlich (1136) Blöcke von Objekten, deren Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie übereinstimmt.
Wenn das empfangene Objekt größer als eine festgelegte Größe (z. B. die Segment- oder Blockgröße) ist, wird das Objekt in mehrere Segmente 238 und/oder mehrere Blöcke 1016 gespalten. In einigen Instanzen umfasst (1138) das erste Objekt 226 zwei oder mehr Objektsegmente. Typischerweise unterscheidet sich (1138) das zweite Objektsegment vom ersten Objektsegment. (Das Vorhandensein zweier identischer Segmente innerhalb eines einzigen Objekts ist selten, kann aber vorkommen, zum Beispiel wenn ein Objekt einen sehr großen Anteil leeren Platzes hatte.) In bestimmten Fällen wird das zweite Objektsegment in einem zweiten, vom ersten Journal unterschiedlichen Journal 232 gespeichert (1140), dessen zugewiesene Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie übereinstimmt. Das zweite Journal speichert ausschließlich (1140) Objektsegmente für Objekte, deren Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie übereinstimmt. Auf diese Weise könnte ein Objekt, das viele Segmente umfasst, die Segmente über viele verschiedene Journals verteilt haben.
In einigen Implementierungen verschlüsselt (1142) der Prozess die Daten für jedes Objektsegment und speichert (1142) einen Entschlüsselungsschlüssel für jedes Objektsegment in den globalen Metadaten. Dies wurde oben in den 10A und 10B veranschaulicht. In einigen Implementierungen wird, wenn ein Segment in mehrere Blöcke gespalten wird, jeder der Blöcke innerhalb des Segments mit demselben Verschlüsselungsschlüssel verschlüsselt und kann somit mit demselben Entschlüsselungsschlüssel entschlüsselt werden. In anderen Implementierungen verfügt jeder Block über seinen eigenen Entschlüsselungsschlüssel, welcher als Teil des Blockindexes 1010 oder 1026 gespeichert werden kann. In Implementierungen, die den Entschlüsselungsschlüssel 1040 in den globalen Metadaten 1002 speichern, kann ein Segment de facto schlicht durch Löschen (1144) des Entschlüsselungsschlüssel gelöscht werden. Auf das Segment kann nicht zugegriffen werden, da es keinen Weg gibt, die Daten für das ursprüngliche Segment wiederherzustellen. Dies hat einige Vorteile. Erstens ist das Löschen eines Segments schnell und effektiv. Zweitens, da es kein reales Risiko gibt, dass auf die gelöschten Daten zugegriffen werden könnte, kann ein effizienterer Abfallsammlungsprozess implementiert werden. Insbesondere kann die Abfallsammlung auf geeignete Intervalle terminiert werden und die physische Löschung der Daten von der Festplatte stapelweise erfolgen. Da Komprimierung ein ressourcenintensiver Vorgang ist, kann die Möglichkeit, viele Löschungen stapelweise zu verarbeiten, die Effizienz drastisch erhöhen. Drittens erfordern einige Implementierungen keine physische Löschung von Speicherplatz, weil der verschlüsselte „Unsinn” nicht zurück in bedeutsame Inhalte konvertiert werden kann.
Der Prozess 1100 speichert (1146) globale Metadaten für das erste Objekt. Dies wurde oben in den 3–5, 10A und 10B veranschaulicht. Die globalen Metadaten 1002 beinhalten (1148) eine erste Liste an Objeksegmenten, die mit dem ersten Objekt korrespondiert. Insbesondere beinhaltet (1150) die erste Liste eine Objektkennung 330 für das erste Objektsegment 238. Die globalen Metadaten 1002 identifizieren ebenfalls das Journal, in dem jedes Segment gespeichert wird, außerdem die Standorte für jedes der Journals.
Zusätzlich zu den globalen Metadaten 1002, werden für jedes Journal 232 lokale Metadaten 1004 gespeichert. In einigen Implementierungen werden die lokalen Metadaten 1004 für jedes Journal im Header 702 des Journals 232 selbst gespeichert. In anderen Implementierungen werden die lokalen Metadaten 1004 separat vom Journal gespeichert. Bei der separaten Speicherung können die lokalen Metadaten 1004 für jedes Journal separat gespeichert werden (z. B. in einer unterschiedlichen, mit jedem Journal korrespondieren Metadatendatei), oder die lokalen Metadaten können gemeinsam gruppiert werden (z. B. in einer Datenbank).
Die erste Instanz speichert (1152) lokale Metadaten 1004 für das erste Objektsegment 238. Die lokalen Metadaten 1004 beinhalten (1154) eine Blockliste, welche jeden Block in der Vielzahl von Blöcken identifiziert. Beachten Sie, dass die Blockliste in den lokalen Metadaten 1004, nicht in den globalen Metadaten 1002 gespeichert wird. Die in den lokalen Metadaten 1004 gespeicherte Blockliste 1006 hält nach, wie die Blöcke innerhalb jedes Journals zugeteilt werden. Die lokalen Metadaten für das erste Journal 232 werden dem ersten Journal 232 zugewiesen (1156). In einigen Implementierungen wird die Zuweisung der lokalen Metadaten zu einem Journal durchgeführt, indem die lokalen Metadaten im Journal gespeichert werden, was bedeutet, dass das Journal in sich geschlossener ist. In einigen Implementierungen werden die lokalen Metadaten für das Journal 232 separat gespeichert (z. B. in einer separaten Datei) und dem Journal zugewiesen (z. B. indem die Journal-ID 370 im Namen des Journal und im Namen der zugewiesenen Metadatendatei beinhaltet werden). In Implementierungen, welche die lokalen Metadaten in einer Datenbank speichern, ist die Journal-ID 370 typischerweise Teil des Hauptschlüssels für die Metadatentabellen.
Dieser Vorgang des Empfangens von Objekten 226 und der Speicherung der Segmente 238 im ersten Journal 232 wird für eine Vielzahl von Objekten 226, deren zugewiesene Platzierungs-Richtlinie 338 mit der Erstplatzierungs-Richtlinie 212 übereinstimmt, solange wiederholt (1158), bis dass eine erste Beendigungsbedingung eintrifft. In einigen Implementierungen tritt die erste Beendigungsbedingung ein, wenn (1160) die Größe des ersten Journals einen zuvor festgelegten Grenzwert überschreitet. In einigen Implementierungen tritt die erste Beendigungsbedingung ein, wenn (1162) das erste Journal für eine zuvor festgelegte Zeitspanne offen gewesen ist. Einige Implementierungen verbinden Größe und Zeit auf verschiedene Arten und Weisen. Zum Beispiel bestimmen einige Implementierungen sowohl eine Zeitspanne als auch ein Größenlimit und die Beendigungsbedingung ist diejenige, welche als erstes eintritt.
Nachdem die erste Beendigungsbedingung eintritt, wird das erste Journal geschlossen (1164), wodurch die Speicherung weiterer Blöcke im ersten Journal 232 verhindert wird. Im Allgemeinen versichern sich Implementierungen, dass die anderen Journals 232 derselben Platzierungs-Richtlinie weiterhin offen sind (oder ein neues geöffnet wird) bevor sie das erste Journal schließen. Da Objekte zu jeder Zeit ankommen können, ist es wichtig, offene Journals für die Speicherung bereit zu halten.
Nachdem das erste Journal 232 geschlossen wurde, unterliegt das Journal seiner Platzierungs-Richtlinie. Die Erfüllung der Platzierungs-Richtlinie 212 kann das Bewegen eines Journalreplikats, die Erstellung einer neuen Kopie eines Journalreplikats, oder die Löschung eines Journalreplikats erfordern. In bestimmten Fällen wird das erste Journal 232 in einer zweiten Instanz 102 des dezentralen Speichersystems 200 in Übereinstimmung mit der Platzierungs-Richtlinie 212 repliziert (1166). (In anderen Fällen wird ein Replikat des ersten Journals gelöscht.) In Implementierungen, die über offene Haupt- und Neben-Journals 232 und 234 verfügen, werden, sobald sie geschlossen wurden, zwei einander entsprechende geschlossene Journals 230 existieren. Folglich könnte jedes der Replikate als Ausgangspunkt für die Replizierung 1166 verwendet werden. Während des Replizierungsvorgangs 1166 (z. B. als Teil der Transaktion) werden die globalen Metadaten 1002 für das erste Journal aktualisiert (1168), um anzuzeigen, dass es an der zweiten Instanz eine Kopie des Journals gibt. Auf der anderen Seite bleiben die lokalen Metadaten 1004 durch die Replizierung unverändert (1168). Dies wurde oben unter Bezug auf die 8, 10A und 10B beschrieben.
Nachdem ein Journal 230 geschlossen wurde, können die Objektsegmente 238 gelöscht werden. Zum Beispiel kann mit einem Objekt ein Email-Anhang korrespondieren. Wenn der Empfänger einer Email die Email löscht, kann der für den Anhang verwendete Speicher gelöscht werden. Nach einem gewissen Zeitraum entstehen durch die Löschungen Löcher innerhalb jedes Journals und ist es daher nützlich, das Journal zu komprimieren, um verschwendeten Platz zu entfernen. Dies ist vergleichbar mit der Fragmentierung flüchtigen Speichers und mit dem Defragmentierungsprozess, um ungenutzten Platz in einem größeren, fortlaufenden Speicher zu verdichten.
Da ein gespeichertes Objektsegment mit vielen (z. B. hunderten, tausenden oder Millionen) unterschiedlichen Objekten korrespondieren kann, kann ein Objektsegment in einem Journal nur dann gelöscht werden, wenn keine Verweise darauf mehr existieren. Folglich ermittelt (1172) der Prozess 1100, sobald ein erstes geschlossenes Journal 230 ausgewählt (1170) wurde, ein oder mehrere im ersten geschlossenen Journal 230 gespeicherte Objektsegmente, bezüglich derer in den Objektmetadaten 228 keine Verweise existieren. In einigen Implementierungen läuft periodisch ein Abfallsammlungsalgorithmus, um jedes der geschlossenen Journals zu komprimieren (1174). Der Komprimierungsvorgang verdichtet (1174) die gespeicherten Blöcke in einem fortlaufenden Speicher, was die Größe des Journals 230 verringert.
Mit der Zeit können die Journals 230 dadurch klein werden, dass mehr und mehr Objektsegmente gelöscht werden. Die Verwaltung vieler kleiner Journals bedeutet einen Mehraufwand vergleichbar der Verwaltung individueller Objekte, wodurch der Nutzen eines Journalspeichers abnimmt. Um mit dieser Problematik umzugehen heften (1176) einige Implementierungen zwei oder mehr geschlossene Journals zusammen, um ein einziges Ersatzjournal zu bilden, und aktualisieren (1176) die Objektmetadaten 228, um anzuzeigen, dass die zuvor in den zwei oder mehr Journals gespeicherten Objektsegmente nun im Ersatzjournal gespeichert werden. Da ein Zusammenheftungsvorgang der Bildung eines vollkommen neuen Journals und der Aktualisierung der Metadaten für alle involvierten Objekte bedarf, wird die Zusammenheftung üblicherweise auf ein Szenario beschränkt, in dem die Journals relativ klein geworden sind.
12 veranschaulicht eine Beispielspeicherung von Segmenten in einem dezentralen Speichersystem in Übereinstimmung mit einigen Implementierungen, wie zuvor unter Bezug auf 10B veranschaulicht. In diesem Beispiel werden die zwei Segmente 238-1 und 238-2 gezeigt. Segment 238-1 ist ein gewöhnliches Segment (d. h. kein Super-Segment) mit der Segment-ID 346-1. Da es sich bei dem Segment 238-1 um ein gewöhnliches Segment handelt, kann es unmittelbar im Segment-/Block-Index 1024 nachgeschlagen werden. In dieser Veranschaulichung wird der Segment-/Blockindex 1024 im Header 702 des Journals 232 gespeichert, in dem die Daten gespeichert werden. Für dieses Segment/diesen Block beträgt der Offset 1028 „y” (1028-y). Unter Verwendung dieses Offsets kann der korrespondierende Block B 1016-B im Speicherplatz 714 gefunden werden.
Bei Segment 238-2 handelt es sich indes um ein Super-Segment mit der (Super-)Segment-ID 346-2. Wie hier veranschaulicht verweist das Super-Segment 238-2 auf einen Eintrag in der Blocklistentabelle 1006. Für jede Super-Segment-ID 1022 existiert eine Vielzahl von korrespondierenden Block-IDs 1008. 12 veranschaulicht zwei korrespondierende Blöcke 1008-1 und 1008-2, aber für sehr große Objekte könnte eine sehr große Anzahl an Blöcken für ein einzelnes Segment existieren. Die Block-IDs 1008-1 und 1008-2 werden dann im Segment-/Blockindex 1024 nachgeschlagen, um die Offsets 1028-x und 1028-z für die Blöcke zu finden. Zuletzt befinden sich die korrespondierenden Blöcke 1016-A und 1016-C unter Verwendung der Offsets 1028-x und 1028-z im Speicherplatz 714. In diesem Beispiel sind die zwei Blöcke nicht fortlaufend und tatsächlich trennt der Block 1016-B von Segment 238-1 die zwei Blöcke von Segment 238-2. Natürlich wird außerdem die Größe jedes Blocks verwendet, sodass nur die eigentlichen Daten jedes Blocks gelesen werden. Dies wurde oben unter Bezug auf die 10B beschrieben.
Implementierungen, die keine gewöhnlichen Segmente (wie etwa Segment 238-1) erlauben, sind vollständig hierarchisch. Beachten Sie außerdem, dass die Zuweisung zwischen Segmenten und Blöcken aufgrund der Implementierung oder aufgrund von anderen dynamischen Faktoren variiert. Zum Beispiel könnte dasselbe Objekt als ein einzelnes Segment mit 100 Blöcken oder als vier Segmente mit jeweils 25 Blöcken gespeichert werden. Einige Implementierungen variieren die Anzahl an Segmenten aufgrund von empirischer Rückmeldungen von der tatsächlichen Verwendung.
Die vorstehende Beschreibung erfolgte zum Zweck der Erklärung unter Bezugnahme auf spezifische Implementierungen. Jedoch sollen die oben stehenden veranschaulichenden Erörterungen nicht erschöpfend sein oder die Erfindung auf die genauen offenbarten Formen beschränken. Angesichts der oben stehenden Lehren sind viele Modifikationen und Abwandlungen möglich. Die Implementierungen wurden ausgewählt und beschrieben, um so gut wie möglich die Prinzipien der Erfindung und deren praktische Anwendungen zu erklären, um dadurch andere Fachkräfte zu befähigen, die Erfindung und unterschiedliche Implementierungen mit verschiedenen Modifizierungen wie für den besonderen in Betracht gezogenen Nutzen so gut wie möglich einsetzen zu können.

Claims

Computersystem für die Platzierungsverwaltung von Objektreplikaten in einem dezentralen Speichersystem mit einer Vielzahl von Instanzen, wobei jede jeweilige Instanz das Folgende umfasst: einen oder mehrere Prozessoren; Speicher; und ein oder mehrere im Speicher abgelegte Programme, wobei das eine oder die mehreren Programme durch einen oder mehrere Prozessoren ausführbare Instruktionen für die Durchführung der nachfolgenden Schritte umfasst: in einer ersten Instanz des dezentralen Speichersystems, das Verfügen über einen oder mehrere Prozessoren und über Speicher, worin der Speicher ein oder mehrere Programme für die Ausführung durch einen oder mehrere Prozessoren speichert: das Empfangen eines ersten Objekts, das einer Erstplatzierungs-Richtlinie zugewiesen ist, worin die Erstplatzierungs-Richtlinie Kriterien dafür festlegt, wo im dezentralen Speichersystem Replikate des ersten Objekts gespeichert werden; das Spalten eines Objekts in eine Vielzahl von Objektsegmenten und die Spaltung eines ersten Objektsegments in eine Vielzahl von Blöcken; das Speichern der Vielzahl von Blöcken in einem ersten Journal, dessen zugewiesene Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie übereinstimmt; das Speichern globaler Metadaten für das erste Objekt, worin die globalen Metadaten eine Liste der Vielzahl von Objektsegmenten beinhaltet und worin die Liste eine jeweilige Kennung für jedes der Objektsegmente beinhaltet; das Speichern lokaler Metadaten für das erste Objektsegment, worin die lokalen Metadaten eine Blockliste beinhalten, die jeden Block einer ersten Vielzahl von Blöcken identifiziert und worin die lokalen Metadaten dem ersten Journal zugewiesen werden; das Replizieren des ersten Journals an eine zweite Instanz des dezentralen Speichersystems in Übereinstimmung mit der Erstplatzierungs-Richtlinie, worin die globalen Metadaten aktualisiert werden, um die Replizierung widerzuspiegeln, wohingegen die lokalen Metadaten durch die Replizierung unverändert bleiben.
Computersystem nach Anspruch 1, worin die globalen Metadaten ein Feld beinhalten, das festlegt, ob es sich bei jedem Objektsegment um einen Block oder eine Liste von Blöcken handelt und worin ein zweites Objektsegment ein Block und das erste Objektsegment eine Liste von Blöcken ist.
Computersystem nach Anspruch 1, worin die globalen Metadaten festlegen, in welchem Journal jedes Objektsegment gespeichert wird und jedes jeweilige Journalreplikat einen Blockindex beinhaltet, der den Standort eines jeden Blocks festlegt, der im jeweiligen Journalreplikat gespeichert ist.
Computersystem nach jedem der Ansprüche 1–3, welches weiterhin an der ersten Instanz umfasst: das Auswählen eines Replikats eines ersten geschlossenen Journals; das Identifizieren eines oder mehrerer im Replikat gespeicherter Objektsegmente, auf welche in den globalen Metadaten keine Verweise existieren; und das Komprimieren des Replikats, wodurch die im Replikat gespeicherten Blöcke in einem fortlaufenden Speicher verdichtet werden.
Computersystem nach jedem der Ansprüche 1–3, worin das dezentrale Speichersystem über eine Vielzahl von Instanzen an geografisch unterschiedlichen Standorten verfügt.
Computersystem nach jedem der Ansprüche 1–3, worin Daten für jedes Objektsegment verschlüsselt und ein Entschlüsselungsschlüssel für jedes Objektsegment in den globalen Metadaten gespeichert wird, Verfahren weiterhin umfassend das de facto Löschen eines Objektsegments durch die Löschung des korrespondierenden Entschlüsselungsschlüssels aus den globalen Metadaten, wodurch der Zugriff auf die Daten des Objekts unmöglich wird.
Computersystem für die Platzierungsverwaltung von Objektreplikaten in einem dezentralen Speichersystem mit einer Vielzahl von Instanzen, wobei jede jeweilige Instanz das Folgende umfasst: einen oder mehrere Prozessoren; Speicher; und ein oder mehrere im Speicher abgelegte Programme, wobei das eine oder die mehreren Programme durch einen oder mehrere Prozessoren ausführbare Instruktionen für die Durchführung der nachfolgenden Schritte umfasst: in einer ersten Instanz des dezentralen Speichersystems, das Verfügen über einen oder mehrere Prozessoren und über Speicher, worin der Speicher ein oder mehrere Programme für die Ausführung durch einen oder mehrere Prozessoren speichert: das Öffnen eines oder mehrerer Journals für die Speicherung von Objektsegmente, worin jedes jeweilige Journal einer einzelnen jeweiligen Platzierungs-Richtlinie zugewiesen wird; das Empfangen eines ersten Objekts, welches wenigstens ein erstes Objektsegment umfasst, worin das erste Objekt einer Erstplatzierungs-Richtlinie zugewiesen wird und worin das erste Objektsegment eine Vielzahl von Blöcken umfasst; das Speichern einer ersten Vielzahl von Blöcken in einem ersten Journal, dessen zugewiesene Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie übereinstimmt, worin das erste Journal ausschließlich Blöcke für Objekte speichert, deren Platzierungs-Richtlinien mit der Erstplatzierungs-Richtlinie übereinstimmen; das Speichern globaler Metadaten für das erste Objekt, worin die globalen Metadaten eine erste Liste von Objektsegmenten beinhalten, die mit dem ersten Objekt korrespondieren und worin die erste Liste eine Kennung für die ersten Objektsegmente beinhaltet; das Speichern lokaler Metadaten für das erste Objektsegment, worin die lokalen Metadaten eine Blockliste beinhalten, die jeden Block einer ersten Vielzahl von Blöcken identifiziert und worin die lokalen Metadaten dem ersten Journal zugewiesen werden; das Wiederholen, für das erste Journal, der Empfangs- und Speicheroperationen für die erste Vielzahl von Objekten, deren zugewiesene Platzierungs-Richtlinien mit der Erstplatzierungs-Richtlinie übereinstimmen, bis eine erste Beendigungsbedingung eintritt; das Schließen des ersten Journals, nachdem die erste Beendigungsbedingung eintritt, wodurch die Speicherung weiterer Blöcke im ersten Journal verhindert wird; und das Replizieren des ersten Journals an eine zweite Instanz des dezentralen Speichersystems in Übereinstimmung mit der Erstplatzierungs-Richtlinie, worin die globalen Metadaten aktualisiert werden, um die Replizierung widerzuspiegeln, wohingegen die lokalen Metadaten durch die Replizierung unverändert bleiben.
Computersystem nach Anspruch 7, worin jedes Objektsegment einen oder mehrere Blöcke umfasst.
Computersystem nach Anspruch 7, worin die globalen Metadaten ein Feld beinhalten, das bestimmt, ob jedes Objektsegment ein Block oder eine Liste von Blöcken ist.
Computersystem nach Anspruch 9, worin ein zweites Objektsegment ein Block und das erste Objektsegment eine Liste von Blöcken ist.
Computersystem nach jedem der Ansprüche 7–10, worin das erste Objekt zwei oder mehr Objektsegmente umfasst, einschließlich eines zweiten, vom ersten Objektsegment unterschiedlichen Objektsegments und worin das zweite Objektsegment in einem zweiten, vom ersten Journal unterschiedlichen Journal gespeichert ist, dessen zugewiesene Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie übereinstimmt.
Computersystem nach jedem der Ansprüche 7–10, worin die globalen Metadaten festlegen, in welchem Journal jedes Objektsegment gespeichert wird und jedes jeweilige Journalreplikat einen Blockindex beinhaltet, der den Standort eines jeden Blocks festlegt, der im jeweiligen Journalreplikat gespeichert ist.
Computersystem nach jedem der Ansprüche 7–10, welches weiterhin an der ersten Instanz das Folgende umfasst: das Auswählen eines Replikats eines ersten geschlossenen Journals; das Identifizieren eines oder mehrerer im Replikat gespeicherter Objektsegmente, auf welche in den globalen Metadaten keine Verweise existieren; und das Komprimieren des Replikats, wodurch die im Replikat gespeicherten Blöcke in einem fortlaufenden Speicher verdichtet werden.
Computersystem nach jedem der Ansprüche 7–10, worin jede Platzierungs-Richtlinie eine Zielanzahl an Objektreplikaten und eine Zielanzahl an Standorten für die Objektreplikate bestimmt.
Computersystem nach jedem der Ansprüche 7–10, worin das dezentrale Speichersystem über eine Vielzahl von Instanzen an geografisch unterschiedlichen Standorten verfügt.
Computersystem nach jedem der Ansprüche 7–10, worin Daten für jedes Objektsegment verschlüsselt werden und ein Entschlüsselungsschlüssel für jedes Objektsegment in den globalen Metadaten gespeichert wird.
Computersystem nach Anspruch 16, welches weiterhin das de facto Löschen eines Objektsegments durch das Löschen des korrespondierenden Entschlüsselungsschlüssels aus den globalen Metadaten umfasst, wodurch der Zugriff auf die Daten des Objekts unmöglich wird.
Nicht-flüchtiges computerlesbares Speichermedium mit darauf gespeicherten Programmen für die Platzierungsverwaltung von Objektreplikaten in einem dezentralen Speichersystem, das über eine Vielzahl von Instanzen verfügt, wobei jede jeweilige Instanz einen oder mehrere Prozessoren und Speicher beinhaltet; wobei das eine oder die mehreren Programme durch den einen oder die mehreren Prozessoren ausführbare Instruktionen für die Durchführung der nachfolgenden Schritte beinhalten: in einer ersten Instanz des dezentralen Speichersystems, das Verfügen über einen oder mehrere Prozessoren und über Speicher, worin der Speicher ein oder mehrere Programme für die Ausführung durch einen oder mehrere Prozessoren speichert: das Empfangen eines ersten Objekts, das einer Erstplatzierungs-Richtlinie zugewiesen ist, worin die Erstplatzierungs-Richtlinie Kriterien dafür festlegt, wo im dezentralen Speichersystem Replikate des ersten Objekts gespeichert werden; das Spalten eines Objekts in eine Vielzahl von Objektsegmenten und die Spaltung eines ersten Objektsegments in eine Vielzahl von Blöcken; das Speichern der Vielzahl von Blöcken in einem ersten Journal, dessen zugewiesene Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie übereinstimmt; das Speichern globaler Metadaten für das erste Objekt, worin die globalen Metadaten eine Liste der Vielzahl von Objektsegmenten beinhaltet und worin die Liste eine jeweilige Kennung für jedes der Objektsegmente beinhaltet; das Speichern lokaler Metadaten für das erste Objektsegment, worin die lokalen Metadaten eine Blockliste beinhalten, die jeden Block einer ersten Vielzahl von Blöcken identifiziert und worin die lokalen Metadaten dem ersten Journal zugewiesen werden; das Replizieren des ersten Journals an eine zweite Instanz des dezentralen Speichersystems in Übereinstimmung mit der Erstplatzierungs-Richtlinie, worin die globalen Metadaten aktualisiert werden, um die Replizierung widerzuspiegeln, wohingegen die lokalen Metadaten durch die Replizierung unverändert bleiben.
Nicht-flüchtiges computerlesbares Speichermedium nach Anspruch 18, worin die globalen Metadaten ein Feld beinhalten, das festlegt, ob es sich bei jedem Objektsegment um einen Block oder eine Liste von Blöcken handelt und worin ein zweites Objektsegment ein Block und das erste Objektsegment eine Liste von Blöcken ist.
Nicht-flüchtiges computerlesbares Speichermedium nach Anspruch 18, worin die globalen Metadaten festlegen, in welchem Journal jedes Objektsegment gespeichert wird und jedes jeweilige Journalreplikat einen Blockindex beinhaltet, der den Standort eines jeden Blocks festlegt, der im jeweiligen Journalreplikat gespeichert ist.
Nicht-flüchtiges computerlesbares Speichermedium nach jedem der Ansprüche 18–20, welches weiterhin an der ersten Instanz umfasst: das Auswählen eines Replikats eines ersten geschlossenen Journals; das Identifizieren eines oder mehrerer im Replikat gespeicherter Objektsegmente, auf welche in den globalen Metadaten keine Verweise existieren; und das Komprimieren des Replikats, wodurch die im Replikat gespeicherten Blöcke in einem fortlaufenden Speicher verdichtet werden.
Nicht-flüchtiges computerlesbares Speichermedium nach jedem der Ansprüche 18–20, worin das dezentrale Speichersystem über eine Vielzahl von Instanzen an geografisch unterschiedlichen Standorten verfügt.
Nicht-flüchtiges computerlesbares Speichermedium nach jedem der Ansprüche 18–20, worin Daten für jedes Objektsegment verschlüsselt und ein Entschlüsselungsschlüssel für jedes Objektsegment in den globalen Metadaten gespeichert wird, Verfahren weiterhin umfassend das de facto Löschen eines Objektsegments durch die Löschung des korrespondierenden Entschlüsselungsschlüssels aus den globalen Metadaten, wodurch der Zugriff auf die Daten des Objekts unmöglich wird.
Nichttransitorisches computerlesbares Speichermedium mit darauf gespeicherten Programmen für die Platzierungsverwaltung von Objektreplikaten in einem dezentralen Speichersystem, das über eine Vielzahl von Instanzen verfügt, wobei jede jeweilige Instanz einen oder mehrere Prozessoren und Speicher beinhaltet; wobei das eine oder die mehreren Programme durch den einen oder die mehreren Prozessoren ausführbare Instruktionen für die Durchführung – der nachfolgenden Schritte beinhalten: in einer ersten Instanz des dezentralen Speichersystems, das Verfügen über einen oder mehrere Prozessoren und über Speicher, worin der Speicher ein oder mehrere Programme für die Ausführung durch einen oder mehrere Prozessoren speichert: das Öffnen eines oder mehrerer Journals für die Speicherung von Objektsegmente, worin jedes jeweilige Journal einer einzelnen jeweiligen Platzierungs-Richtlinie zugewiesen wird; das Empfangen eines ersten Objekts, welches wenigstens ein erstes Objektsegment umfasst, worin das erste Objekt einer Erstplatzierungs-Richtlinie zugewiesen wird und worin das erste Objektsegment eine Vielzahl von Blöcken umfasst; das Speichern einer ersten Vielzahl von Blöcken in einem ersten Journal, dessen zugewiesene Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie übereinstimmt, worin das erste Journal ausschließlich Blöcke für Objekte speichert, deren Platzierungs-Richtlinien mit der Erstplatzierungs-Richtlinie übereinstimmen; das Speichern globaler Metadaten für das erste Objekt, worin die globalen Metadaten eine erste Liste von Objektsegmenten beinhalten, die mit dem ersten Objekt korrespondieren und worin die erste Liste eine Kennung für die ersten Objektsegmente beinhaltet; das Speichern lokaler Metadaten für das erste Objektsegment, worin die lokalen Metadaten eine Blockliste beinhalten, die jeden Block einer ersten Vielzahl von Blöcken identifiziert und worin die lokalen Metadaten dem ersten Journal zugewiesen werden; das Wiederholen, für das erste Journal, der Empfangs- und Speicheroperationen für die erste Vielzahl von Objekten, deren zugewiesene Platzierungs-Richtlinien mit der Erstplatzierungs-Richtlinie übereinstimmen, bis eine erste Beendigungsbedingung eintritt; das Schließen des ersten Journals, nachdem die erste Beendigungsbedingung eintritt, wodurch die Speicherung weiterer Blöcke im ersten Journal verhindert wird; und das Replizieren des ersten Journals an eine zweite Instanz des dezentralen Speichersystems in Übereinstimmung mit der Erstplatzierungs-Richtlinie, worin die globalen Metadaten aktualisiert werden, um die Replizierung widerzuspiegeln, wohingegen die lokalen Metadaten durch die Replizierung unverändert bleiben.
Nichttransitorisches computerlesbares Speichermedium nach Anspruch 24, worin jedes Objektsegment einen oder mehrere Blöcke umfasst.
Nichttransitorisches computerlesbares Speichermedium nach Anspruch 24, worin die globalen Metadaten ein Feld beinhalten, das bestimmt, ob jedes Objektsegment ein Block oder eine Liste von Blöcken ist.
Nichttransitorisches computerlesbares Speichermedium nach Anspruch 26, worin ein zweites Objektsegment ein Block und das erste Objektsegment eine Liste von Blöcken ist.
Nichttransitorisches computerlesbares Speichermedium nach jedem der Ansprüche 24–27, worin das erste Objekt zwei oder mehr Objektsegmente umfasst, einschließlich eines zweiten, vom ersten Objektsegment unterschiedlichen Objektsegments und worin das zweite Objektsegment in einem zweiten, vom ersten Journal unterschiedlichen Journal gespeichert ist, dessen zugewiesene Platzierungs-Richtlinie mit der Erstplatzierungs-Richtlinie übereinstimmt.
Nichttransitorisches computerlesbares Speichermedium nach jedem der Ansprüche 24–27, worin die globalen Metadaten festlegen, in welchem Journal jedes Objektsegment gespeichert wird und jedes jeweilige Journalreplikat einen Blockindex beinhaltet, der den Standort eines jeden Blocks festlegt, der im jeweiligen Journalreplikat gespeichert ist.
Nichttransitorisches computerlesbares Speichermedium nach jedem der Ansprüche 24–27, welches weiterhin an der ersten Instanz das Folgende umfasst: das Auswählen eines Replikats eines ersten geschlossenen Journals; Objektsegmente, auf welche in den globalen Metadaten keine Verweise existieren; und das Komprimieren des Replikats, wodurch die im Replikat gespeicherten Blöcke in einem fortlaufenden Speicher verdichtet werden.
Nichttransitorisches computerlesbares Speichermedium nach jedem der Ansprüche 24–27, worin jede Platzierungs-Richtlinie eine Zielanzahl an Objektreplikaten und eine Zielanzahl an Standorten für die Objektreplikate bestimmt.
Nichttransitorisches computerlesbares Speichermedium nach jedem der Ansprüche 24–27, worin das dezentrale Speichersystem über eine Vielzahl von Instanzen an geografisch unterschiedlichen Standorten verfügt.
Nichttransitorisches computerlesbares Speichermedium nach jedem der Ansprüche 24–27, worin Daten für jedes Objektsegment verschlüsselt werden und ein Entschlüsselungsschlüssel für jedes Objektsegment in den globalen Metadaten gespeichert wird.
Nichttransitorisches computerlesbares Speichermedium nach Anspruch 33, welches weiterhin das de facto Löschen eines Objektsegments durch das Löschen des korrespondierenden Entschlüsselungsschlüssels aus den globalen Metadaten umfasst, wodurch der Zugriff auf die Daten des Objekts unmöglich wird.