Objektspeicher

Objektspeicher (auch bekannt als objektbasierter Speicher[1] oder Objektmassenspeicher) ist eine
Speicherarchitektur, die Daten als Objekte verwaltet, im Gegensatz zu anderen Architekturen wie
Dateisystemen, die Daten als Dateihierarchie oder Blockspeicher, die Daten als Datenblöcke in Sektoren
und Spuren verwalten.[2] Typischerweise enthält jedes Objekt selbst die Nutzdaten, eine variable Menge an
Metadaten, und einen global eindeutigen Identifikator. Objektspeicher können auf vielen Ebenen umgesetzt
werden: Einschließlich der Geräteebene (Objektspeichergerät), der Systemebene oder der
Schnittstellenebene. In jedem Fall versucht Objektspeicher Fähigkeiten bereitzustellen, die von anderen
Speicherarchitekturen nicht berücksichtigt werden, wie von Anwendungen direkt programmierbare
Schnittstellen, ein Namensraum der mehrere Instanzen physischer Geräte überspannen kann und
Datenverwaltungsfunktionen wie Datenreplikation und -verteilung mit Unterteilung auf Objektebene.

Objektspeichersysteme ermöglichen die Aufbewahrung riesiger Mengen unstrukturierter Daten. So werden

Objektspeicher beispielsweise für die Speicherung von Fotos bei Facebook, Liedern bei Spotify oder
Dateien bei Online-Kollaborationsdiensten wie Dropbox verwendet.[3]

Inhaltsverzeichnis
Geschichte
Anfänge
Entwicklung
Architektur
Abstraktion des Speichers
Einbezug von umfangreichen benutzerdefinierten Metadaten in das Objekt
Programmatische Datenverwaltung
Implementierung
Datenwolke
Objektbasierte Dateisysteme
Objektspeichersysteme
Hybridspeicher
Unternehmenseigene Objektspeicher
Speicher virtueller Objekte
Objektbasierte Speichergeräte
Marktakzeptanz
Marktanalyse
Standards
Standards für Geräte mit objektbasiertem Speicher
OSD Version 1
OSD Version 2
Unterschiede zwischen Schlüssel-Wert- und Objektspeichern
Siehe auch
Einzelnachweise

Geschichte

Anfänge

1995 führten Forschungsarbeiten von Garth Gibson zu Network-Attached Secure Disks erstmals das
Konzept der Trennung weniger gebräuchlicher Operationen, wie Namensraummanipulationen von
häufigeren Operationen, wie Lese- und Schreibzugriffen ein. Dies sollte sowohl Leistung als auch
Skalierbarkeit verbessern.[4] Im selben Jahr wurde das belgisches Unternehmen FilePool gegründet um die
Grundlage für Archivierungsfunktionen zu schaffen. Objektspeicher wurden 1996 in Gibsons Labor an der
Carnegie Mellon University als Forschungsprojekt vorgeschlagen.[5] Ein weiteres Schlüsselkonzept war
die Abstrahierung der Schreib- und Lesevorgänge von Daten in flexiblere Datencontainer (Objekte). Die
feinkörnige Zugriffskontrolle durch die Objektspeicherarchitektur[6] wurde von einem Mitglied des NASD-
Teams, Howard Gobioff, beschrieben, der später zu den Erfindern des Google File Systems gehörte.[7] Zu
den weiteren verwandten Arbeiten gehört das Coda-Dateisystem-Projekt an der Carnegie-Mellon-
Universität, das 1987 begann und aus dem das Lustre-Dateisystem hervorging.[8] Ein weiteres Projekt war
das OceanStore-Projekt an der UC Berkeley,[9], das 1999 und das Logistical Networking Project an der
University of Tennessee in Knoxville, das 1998 begann. 1999 gründete Gibson Panasas um die von der
NASD-Gruppe entwickelten Konzepte zu vermarkten.

Entwicklung

Seagate Technology spielte eine zentrale Rolle bei der Entwicklung von Objektspeichern. Laut der Storage
Networking Industry Association SNIA, “entstand Objektspeicher in den späten 1990er Jahren: Seagate-
Spezifikationen aus dem Jahr 1999 stellten einige der ersten Befehle vor und zeigten, wie das
Betriebssystem effektiv von der Nutzung des Speichers ferngehalten werden kann.”[10]

Eine vorläufige Version des “OBJECT BASED STORAGE DEVICES Command Set Proposal” vom 25.
Oktober 1999 wurde von Seagate unter der Leitung von Dave Anderson eingereicht und war das Ergebnis
der Arbeit des National Storage Industry Consortium (NSIC) mit Beiträgen der Carnegie-Mellon-
Universität, Seagate, IBM, Quantum und StorageTek.[11] Diese Abhandlung wurde dem INCITS T-10
(Internationalen Komitee für Informationstechnikstandards) mit dem Ziel vorgeschlagen, einen Ausschuss
zu bilden und eine Spezifikation auf der Grundlage des SCSI-Schnittstellenprotokolls zu entwickeln. Darin
wurden Objekte als abstrahierte Daten mit eindeutigen Bezeichnern und Metadaten definiert, und es wurde
dargelegt, wie Objekte mit Dateisystemen zusammenhängen, zusammen mit vielen anderen innovativen
Konzepten. Anderson stellte viele dieser Ideen auf der SNIA-Konferenz im Oktober 1999 vor.  Die
Präsentation enthüllte eine Vereinbarung über geistiges Eigentum, die im Februar 1997 zwischen den
ursprünglichen Kooperationspartnern unterzeichnet worden war (wobei Seagate durch Anderson und Chris
Malakapalli vertreten wurde) und die Vorteile von Objektspeichern, skalierbarem Computing,
Plattformunabhängigkeit und Speichermanagement umfasste.[12]

Architektur

Abstraktion des Speichers

Eines der Entwurfsprinzipien der Objektspeicherung besteht darin,
einige der unteren Ebenen der Speicherung von Administration und
Anwendungen zu abstrahieren. So werden Daten als Objekte,
anstelle von Dateien oder Blöcken bereitgestellt und verwaltet.
Objekte enthalten zusätzliche beschreibende Eigenschaften, die für
eine bessere Indizierung oder Verwaltung verwendet werden
können. Administratoren müssen keine Speicherfunktionen auf
unterer Ebene ausführen, wie z. B. die Erstellung und Verwaltung
logischer Volumes zur Nutzung der Festplattenkapazität oder die
Einrichtung von RAID-Levels für den Fall eines Festplattenausfalls vornehmen.

Die Objektspeicherung ermöglicht auch die Adressierung und Identifizierung einzelner Objekte durch mehr
als nur Dateinamen und Dateipfad. Die Objektspeicherung fügt einen eindeutigen Bezeichner innerhalb
eines Objektbehälters (engl. bucket [dt. Eimer, Kübel]) oder im gesamten System hinzu, um erheblich
größere Namensräume zu unterstützen und Namenskollisionen zu vermeiden.

Einbezug von umfangreichen benutzerdefinierten Metadaten in das

Objekt

Bei der Objektspeicherung werden die Dateimetadaten ausdrücklich von den Nutzdaten getrennt, um
zusätzliche Funktionen zu unterstützen.
Im Gegensatz zu festen Metadaten in Dateisystemen (Dateiname,
Erstellungsdatum, Typ usw.) bietet die Objektspeicherung voll funktionsfähige, benutzerdefinierte
Metadaten auf Objektebene, um:

Erfassen anwendungsspezifischer oder benutzerspezifischer Informationen für eine bessere

Indizierung
Unterstützung von Datenverwaltungsrichtlinien (z. B. eine Richtlinie für die Verschiebung
von Objekten von einer Speicherebene zur anderen)
Zentralisierung der Speicherverwaltung über viele einzelne Knoten und Verbünde hinweg
Optimierung der Metadatenspeicherung (z. B. gekapselte, datenbankgestützte oder
Schlüssel-Wert-Speicherung) und der Zwischenspeicherung/Indizierung (wenn
maßgebliche Metadaten mit den Metadaten innerhalb des Objekts gekapselt sind)
unabhängig von der Datenspeicherung (z. B. unstrukturierte binäre Speicherung)

Darüber hinaus gibt es in einigen objektbasierten Dateisystem-Implementierungen:

Die Dateisystemnutzerteile kontaktieren die Metadatendienst nur einmal, wenn die Datei
geöffnet wird und erhalten den Inhalt dann direkt über die Objektspeicherdienste (im
Gegensatz zu blockbasierten Dateisystemen, die einen ständigen Zugriff auf die Metadaten
erfordern würden).
Datenobjekte können auf Dateibasis konfiguriert werden, um eine adaptive Stripe-Breite zu
ermöglichen, sogar über mehrere Objektspeicher-Server hinweg, was Optimierungen bei
Bandbreite und E/A ermöglicht.

objektbasierte Speichergeräte (engl. OSD) wie auch einige Software-Implementierungen (z. B. Caringo
Swarm) verwalten Metadaten und Nutzdaten auf Ebene des Speichergerätes:

Anstelle einer blockorientierten Schnittstelle, die Datenblöcke fester Größe liest und
schreibt, werden die Daten in Datencontainern flexibler Größe organisiert, die als Objekte
bezeichnet werden.
 Jedes Objekt hat sowohl Nutzdaten (eine uninterpretierte Folge von Bytes) als auch
Metadaten (eine erweiterbare Menge von Attributen, die das Objekt beschreiben); die
physische Kapselung beider zusammen verbessert die Wiederherstellbarkeit.
Die Befehlsschnittstelle enthält Befehle zum Erstellen und Löschen von Objekten, zum
Schreiben und Lesen von Bytes in und aus einzelnen Objekten sowie zum Setzen und
Abrufen von Attributen für Objekte
Sicherheitsmechanismen bieten Zugriffskontrolle pro Objekt und pro Befehl

Programmatische Datenverwaltung

Objektspeicher bieten programmatische Schnittstellen, die es Anwendungen ermöglichen, Daten zu

manipulieren. Auf der Basisebene umfasst dies Funktionen zum Erstellen, Lesen, Aktualisieren und
Löschen (engl. CRUD) für grundlegende Lese-, Schreib- und Löschvorgänge. Einige
Objektspeicherimplementierungen gehen darüber hinaus und unterstützen zusätzliche Funktionen wie
Objektversionierung, Objektreplikation, Lebenszyklusverwaltung und die Bewegung von Objekten
zwischen verschiedenen Speicherebenen und -typen.
Die meisten API-Implementierungen sind REST-
basiert und ermöglichen die Verwendung vieler Standard-HTTP-Aufrufe.

Das Aktualisieren und Löschen von Objekten kann Auswirkungen auf andere Objekte oder Metadaten
haben, die Referenzen zu dem geänderten oder entfernten Objekt haben. Die Zusammenhänge können so
komplex sein, dass es für Programmierer und Anwender nicht möglich ist, mit vertretbarem Aufwand
zuverlässig zu entscheiden, ob ein bestimmtes Objekt im Speicher gelöscht werden darf, ohne dass es zu
einer technischen Kompromittierung von anderen Objekten oder zu Speicherlecks kommen kann. Für
geschlossene Systeme, in denen Objekte gelöscht werden dürfen, bietet es sich gegebenenfalls an, in
regelmäßigen Abständen eine geeignete automatische Speicherbereinigung durchzuführen.[13]

Implementierung

Datenwolke

Die überwiegende Mehrheit der auf dem Markt erhältlichen Cloud-Speicher basiert auf einer
Objektspeicherarchitektur. Einige nennenswerte Beispiele sind Amazon Web Services S3, welches im
März 2006 debütierte, Microsoft Azure Blob Storage, Rackspace Files (dessen Code im Jahr 2010 dem
Openstack-Projekt als OpenStack Swift gespendet wurde) und Google Cloud Storage, veröffentlicht im
Mai 2010.

Objektbasierte Dateisysteme

Einige verteilte Dateisysteme verwenden eine objektbasierte Architektur, bei der Dateimetadaten in
Metadatenservern und Dateidaten in Objektspeicherservern gespeichert werden. Die Client-Software des
Dateisystems interagiert mit den verschiedenen Servern und abstrahiert sie, um den Benutzern und
Anwendungen ein vollständiges Dateisystem zu präsentieren.

Objektspeichersysteme

Einige frühe Versionen von Objektspeichern wurden für die Archivierung verwendet, da die
Implementierungen für Datendienste wie Unveränderlichkeit und nicht für Leistung optimiert waren. EMC
Centera und Hitachi HCP (zuvor als HCAP bekannt) sind zwei häufig erwähnte Objektspeicherprodukte
für die Archivierung. Ein weiteres Beispiel ist die Quantum Lattus Object Storage Platform.

Allgemeinere Objektspeichersysteme kamen um 2008 auf den Markt. Angelockt durch das unglaubliche
Wachstum "firmeneigener" Speichersysteme in Webanwendungen wie Yahoo Mail und den frühen Erfolg
von Cloud-Storage versprachen Objektspeichersysteme den Umfang und die Fähigkeiten von Cloud-
Storage mit der Möglichkeit, das System innerhalb eines Unternehmens oder bei einem aufstrebenden
Cloud-Storage-Dienstanbieter einzusetzen.

Hybridspeicher

Einige wenige Objektspeichersysteme unterstützen Unified File and Object (UFO)-Speicher, so dass einige
Clients Objekte auf einem Speichersystem speichern können, während andere Clients gleichzeitig Dateien
auf demselben Speichersystem speichern. Obwohl der Begriff "Hybridspeicher" aufgrund der
Verwechslung mit hybriden Festplatten- und Flash-Speichern nicht weit verbreitet ist[14], gibt es in einigen
Objektspeicherprodukten interoperable Schnittstellen für dieselben Daten.

Unternehmenseigene Objektspeicher

Einige große Internetunternehmen haben ihre eigene Software entwickelt, als Objektspeicherprodukte noch
nicht im Handel erhältlich waren oder die Anwendungsfälle sehr spezifisch waren. Facebook hat seine
eigene Objektspeicher-Software mit dem Codenamen Haystack entwickelt, um seine besonderen
Anforderungen an die Verwaltung von Fotos in großem Maßstab effizient zu erfüllen.[15]

Speicher virtueller Objekte

Zusätzlich zu Objektspeichersystemen, die Eigentümer der verwalteten Dateien sind, bieten einige Systeme
eine Objektabstraktion über einer oder mehreren traditionellen dateisystembasierten Lösungen. Diese
Lösungen verfügen nicht über den zugrunde liegenden Rohspeicher, sondern spiegeln aktiv die
Dateisystemänderungen und replizieren sie in ihrem eigenen Objektkatalog, zusammen mit allen
Metadaten, die automatisch aus den Dateien extrahiert werden können. Die Benutzer können dann
zusätzliche Metadaten über die APIs des virtuellen Objektspeichers hinzufügen. In der Regel werden ein
globaler Namensraum und Replikationsmöglichkeiten sowohl innerhalb als auch zwischen Dateisystemen
unterstützt.

Die meisten Produkte in dieser Kategorie wurden in letzter Zeit um Fähigkeiten erweitert, um auch andere
Objektspeicherlösungen zu unterstützen.

Objektbasierte Speichergeräte

Die Objektspeicherung auf der Protokoll- und Geräteebene wurde vor 20 Jahren vorgeschlagen und vor
fast 10 Jahren als "Object-based Storage Device Commands" (OSD) für den SCSI-Befehlssatz
angenommen,[16] wurde jedoch erst mit der Seagate Kinetic Open Storage-Plattform zur Anwendung
gebracht.[17][18] Der SCSI-Befehlssatz für Objektspeichergeräte wurde von einer Arbeitsgruppe der SNIA
für das T10-Komitee des International Committee for Information Technology Standards (INCITS).[19]
T10 ist für alle SCSI-Standards verantwortlich.

Marktakzeptanz
Eines der ersten Objektspeicherprodukte, Lustre, wird in 70 % der Top-100-Supercomputer und ~50% der
Top 500 verwendet.[20] Stand 16. Juni 2013 schließt dies 7 der oberen 10, einschließlich des aktuell
viertschnellsten Systems auf der Liste - Chinas Tianhe-2 und den siebenschnellsten, den Titan
Supercomputer am Oak Ridge National Laboratory ein.[21]

Objektspeichersysteme wurden in den frühen 2000er Jahren als Archivierungsplattform gut angenommen,
insbesondere im Zuge von Komplianzgesetzen wie Sarbanes-Oxley. Nach fünf Jahren auf dem Markt
konnte das EMC-Produkt Centera bis 2007 mehr als 3500 Kunden und 150 Petabytes an ausgelieferten
Daten verzeichnen.[22] Hitachis HCP-Produkt hat ebenfalls viele Kunden im Petabyte-Bereich.[23] Neuere
Objektspeichersysteme sind ebenfalls auf dem Vormarsch, insbesondere bei sehr großen
benutzerdefinierten Anwendungen wie eBays Auktionsportal, wo EMC Atmos verwendet wird um über
500 Millionen Objekte pro Tag zu verwalten.[24] Mit Stand vom 3. März 2014 hat EMC nach eigenen
Angaben über 1,5 Exabyte Atmos-Speicher verkauft.[25] Am 1. Juli 2014 entschied sich das Los Alamos
National Laboratory für Scality RING als Basis für eine Speicherumgebung von 500 Petabyte, die zu den
größten überhaupt gehört.[26]

Unternehmenseigene Objektspeichersysteme wie Facebooks Haystack haben eine beeindruckende

Skalierung erreicht. Stand April 2009 verwaltet Haystack 60 Milliarden Fotos und 1,5 Petabyte
Speicherplatz und wächst um 220 Millionen Fotos und 25 Terabyte pro Woche.[15] Facebook gab kürzlich
bekannt, dass sie 350 Millionen Fotos pro Tag hinzufügen und insgesamt 240 Milliarden Fotos
speichern.[27] Dies entspricht etwa 357 Petabyte.[28]

Die Speicherung in der Datenwolke ist allgegenwärtig geworden, da viele neue Web- und
Mobilanwendungen sie als gängige Methode zur Speicherung von Binärdaten wählen.[29] Als
Speicherunterbau für viele beliebte Anwendungen wie Smugmug and Dropbox hat AWS S3 eine enorme
Größe erreicht: Im April 2013 wurden über 2 Billionen Objekte gespeichert.[30] Zwei Monate später
behauptete Microsoft, dass sie sogar noch mehr Objekte in Azure speichern, nämlich 8,5 Billionen.[31] Im
April 2014 waren in Azure bereits über 20 Billionen Objekte gespeichert.[32] Windows Azure Storage
verwaltet BLOBs (Benutzerdateien), Tabellen (strukturierter Speicher), Warteschlangen
(Nachrichtenübermittlung) und zählt alle als Objekte.[33]

Marktanalyse
IDC hat damit begonnen, den objektbasierten Speichermarkt jährlich mit seiner MarketScape-Methodik zu
bewerten. Sie beschreibt den MarketScape als: "...eine quantitative und qualitative Bewertung der
Merkmale, die den gegenwärtigen und zukünftigen Erfolg eines Anbieters in dem besagten Markt oder
Marktsegment beurteilen und ein Maß für seinen Aufstieg zu einem Marktführer oder die Beibehaltung
einer Führungsposition bieten. IDC MarketScape-Bewertungen sind besonders hilfreich in aufstrebenden
Märkten, die oft fragmentiert sind, mehrere Akteure haben und keine klaren Marktführer haben."[34]

2019 bewertete IDC Dell EMC, Hitachi Data Systems, IBM, NetApp und Scality als Marktführer.

Standards

Standards für Geräte mit objektbasiertem Speicher

OSD Version 1
In der ersten Version des OSD-Standards[35] werden Objekte mittels einer 64 Bit großen Partitions-ID und
einer 64 Bit großen Objekt-ID identifiziert. Innerhalb eines OSDs werden Partitionen erstellt und gelöscht,
und Objekte werden innerhalb von Partitionen erstellt und gelöscht. mit Partitionen und Objekten sind
keine festen Größen verbunden, sie können beliebig wachsen und unterliegen nur den physischen
Beschränkungen des Gerätes oder logischen Quota-Beschränkungen auf einer Partition.
Ein erweiterbarer
Satz von Attributen beschreibt Objekte. Einige Attribute werden direkt von der OSD implementiert, z. B.
die Anzahl der Bytes in einem Objekt und die Änderungszeit eines Objekts. Es gibt ein spezielles Policy-
Tag-Attribut, das Teil des Sicherheitsmechanismus ist. Andere Attribute werden von der OSD nicht
interpretiert. Sie werden von den übergeordneten Speichersystemen, die das OSD für die dauerhafte
Speicherung nutzen, für Objekte gesetzt. Attribute können z. B. zur Klassifizierung von Objekten oder zur
Erfassung von Beziehungen zwischen verschiedenen Objekten, die auf unterschiedlichen OSDs
gespeichert sind, verwendet werden.
Ein Auflistungsbefehl gibt eine Liste von Identifikatoren für Objekte
innerhalb einer Partition zurück, optional gefiltert durch Übereinstimmungen mit ihren Attributwerten. Ein
Listenbefehl kann auch ausgewählte Attribute der aufgelisteten Objekte zurückgeben.
Lese- und
Schreibbefehle können mit Befehlen zum Abrufen und Setzen von Attributen kombiniert bzw. huckepack
genommen werden. Dadurch muss ein hochrangiges Speichersystem weniger oft die Schnittstelle zum
OSD passieren, was die Gesamteffizienz verbessern kann.

OSD Version 2

Eine zweite Generation des SCSI-Befehlssatzes "Object-Based Storage Devices - 2" (OSD-2)
(objektbasierte Speichergeräte) fügte Unterstützung für Schnappschüsse, Sammlungen von Objekten und
verbesserte Fehlerbehandlung hinzu.[36]

Ein Schnappschuss ist eine zeitpunktgenaue Kopie aller Objekte in einer Partition in eine neue Partition.
Das OSD kann eine platzsparende Kopie mit Hilfe von Copy-on-Write-Techniken implementieren, so dass
die beiden Partitionen Objekte gemeinsam nutzen, die zwischen den Snapshots unverändert sind, oder das
OSD kann die Daten physisch in die neue Partition kopieren. Der Standard definiert Klone, die
beschreibbar sind, und Snapshots, die nur lesbar sind.

Eine Sammlung ist eine besondere Art von Objekt, das die Bezeichner anderer Objekte enthält. Es gibt
Operationen zum Hinzufügen und Löschen von Sammlungen, und es gibt Operationen zum Abrufen oder
Setzen von Attributen für alle Objekte in einer Sammlung. Sammlungen werden auch für Fehlerberichte
verwendet. Wenn ein Objekt durch einen Medienfehler (z. B. eine fehlerhafte Stelle auf der Festplatte) oder
durch einen Softwarefehler innerhalb der OSD-Implementierung beschädigt wird, wird seine Kennung in
eine spezielle Fehlersammlung aufgenommen. Das übergeordnete Speichersystem, das das OSD
verwendet, kann diese Sammlung abfragen und bei Bedarf Korrekturmaßnahmen ergreifen.

Unterschiede zwischen Schlüssel-Wert- und Objektspeichern

Leider ist die Grenze zwischen einem Objektspeicher und einem Schlüssel-Wert-Speicher fließend, so dass
Schlüssel-Wert-Speicher manchmal ungenau als Objektspeicher bezeichnet werden.

Eine herkömmliche Blockspeicherschnittstelle verwendet eine Reihe von Blöcken fester Größe, die bei 0
beginnend nummeriert sind. Die Daten müssen genau diese feste Größe haben und können in einem
bestimmten Block gespeichert werden, der durch seine logische Blocknummer (LBN) identifiziert wird.
Später kann man diesen Datenblock durch Angabe seiner eindeutigen LBN abrufen.

Bei einem Schlüssel-Wert-Speicher werden die Daten durch einen Schlüssel und nicht durch eine LBN
identifiziert. Ein Schlüssel könnte "Katze" oder "Olive" oder "42" sein. Er kann eine beliebige Folge von
Bytes mit beliebiger Länge sein. Die Daten (in diesem Sprachgebrauch Wert genannt) müssen keine feste
Größe haben und können auch eine beliebige Folge von Bytes beliebiger Länge sein. Man speichert Daten,
indem man dem Datenspeicher den Schlüssel und die Daten (Wert) vorlegt, und kann die Daten später
abrufen, indem man den Schlüssel vorlegt. Dieses Konzept findet sich in Programmiersprachen wieder.
Python nennt sie Dictionaries, Perl nennt sie Hashes, Java und C++ nennen sie Maps usw. Mehrere
Datenbanken implementieren auch Schlüssel-Wert-Speicher wie Memcached, Redis und CouchDB.

Objektspeicher ähneln Schlüssel-Wert-Speichern in zweierlei Hinsicht: Erstens kann der Objektidentifikator

oder URL (die Entsprechung zum Schlüssel) eine beliebige Zeichenkette sein.[37] Zweitens können die
Daten von beliebiger Größe sein.

Es gibt jedoch einige wesentliche Unterschiede zwischen Schlüssel-Wert-Speichern und Objektspeichern.

Erstens ermöglichen Objektspeicher auch die Zuordnung einer begrenzten Anzahl von Attributen
(Metadaten) zu den einzelnen Datenelementen. Die Kombination aus einem Schlüssel, einem Wert und
einer Reihe von Attributen wird als Objekt bezeichnet. Zweitens sind Objektspeicher für große
Datenmengen (Hunderte von Megabyte oder sogar Gigabyte) optimiert, während bei Schlüssel-Wert-
Speichern mit relativ kleinen Werten (Kilobytes) gerechnet wird. Schließlich bieten Objektspeicher in der
Regel schwächere Konsistenzgarantien wie z. B. Letztendliche Konsistenz, während Schlüssel-Wert-
Speichern starke Konsistenz bieten.

Siehe auch
Cloud Computing
Cluster-Dateisystem
Object access method

Einzelnachweise
1. Mike Mesnier: Object-Based Storage (http://www.storagevisions.com/White%20Papers/Mes
nierIEEE03.pdf).
2. Yadin Porter De Leon, Tony Piscopo: Object Storage versus Block Storage: Understanding
the Technology Differences (http://www.druva.com/blog/object-storage-versus-block-storage
-understanding-technology-differences/). Druva.com. Abgerufen am 19. Januar 2015.
3. Critical Capabilities for Object Storage (http://www.gartner.com/technology/reprints.do?id=1-
1R78PJ9&ct=140226&st=sb). Gartner Research. 11. Februar 2014.
4. Garth A. Gibson, Nagle D.: File Server Scaling with Network-Attached Secure Disks (http://w
ww.pdl.cmu.edu/ftp/NASD/Sigmetrics97.pdf). Proceedings of the ACM International
Conference on Measurement and Modeling of Computer Systems (Sigmetrics ‘97).
Abgerufen am 27. Oktober 2013.
5. Michael Factor, K. Meth: Object Storage: The Future Building Block for Storage Systems (htt
ps://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.122.3959&rep=rep1&type=pdf).
IBM Haifa Research Labs. Abgerufen am 26. September 2013.
6. Gobioff, Howard, Gibson, Garth A.: Security for Network Attached Storage Devices (CMU-
CS-97-185) (http://repository.cmu.edu/cgi/viewcontent.cgi?article=1147&context=pdl).
Parallel Data Laboratory. 1. Oktober 1997. Abgerufen am 7. November 2013.
7. Sanjay Ghemawat, Howard Gobioff: The Google File System (http://research.google.com/ar
chive/gfs-sosp2003.pdf). October 2003. Abgerufen am 7. November 2013.
8. Peter Braam: Lustre: The intergalactic file system (https://ols.fedoraproject.org/OLS/Reprints-
2002/braam-reprint.pdf). Abgerufen am 17. September 2013.
9. OceanStore (https://web.archive.org/web/20120808163557/http://oceanstore.cs.berkeley.ed
u/). Archiviert vom Original (https://giftbot.toolforge.org/deref.fcgi?url=http%3A%2F%2Focea
nstore.cs.berkeley.edu%2F) am 8. August 2012. Abgerufen am 18. September 2013.
10. Object Storage: What, How and Why?, NSF (Networking Storage Forum), SNIA (Storage
Networking Industry Association), Live Webcast (https://www.snia.org/sites/default/files/ESF/
Object-Sorage-What-How-Why-Final.pdf) February 19, 2020
11. D. Anderson: Object based storage devices: a command set proposal (https://www.semantic
scholar.org/paper/Object-based-storage-devices%3A-a-command-set-Anderson/bcd197cb0f
8544b651289dfdb95efd0b1fd70753). 1999.
12. Object Based Storage: A Vision, slide presentation, Dave Anderson and Seagate
Technology, October 13, 1999 https://www.t10.org/ftp/t10/document.99/99-341r0.pdf
13. Fundamentals of garbage collection (https://docs.microsoft.com/en-us/dotnet/standard/garba
ge-collection/fundamentals), Microsoft, .NET fundamentals, 11. Mai 2022, abgerufen am 16.
Juni 2022
14. George Crump: What Is Hybrid Storage? (http://www.storage-switzerland.com/Articles/Entrie
s/2012/12/17_What_Is_Hybrid_Storage.html). Abgerufen am 16. Februar 2020.
15. Peter Vajgel: Needle in a haystack: efficient storage of billions of photos (https://www.facebo
ok.com/note.php?note_id=76191543919). Abgerufen am 10. September 2013.
16. Erik Riedel, Sami Iren: Object Storage and Applications (https://www.usenix.org/legacy/even
t/lsf07/tech/riedel.pdf). February 2007. Abgerufen am 3. November 2013.
17. The Seagate Kinetic Open Storage Vision (http://www.seagate.com/tech-insights/kinetic-visi
on-how-seagate-new-developer-tools-meets-the-needs-of-cloud-storage-platforms-master-t
i/). Seagate. Abgerufen am 3. November 2013.
18. Sean Gallagher: Seagate introduces a new drive interface: Ethernet (https://arstechnica.co
m/information-technology/2013/10/seagate-introduces-a-new-drive-interface-ethernet/). In:
Arstechnica.com, 27. Oktober 2013. Abgerufen am 3. November 2013. 
19. Jonathan Corbet: Linux and object storage devices (https://lwn.net/Articles/305740/).
4. November 2008. Abgerufen am 8. November 2013.
20. Andreas Dilger: Lustre Future Development (https://web.archive.org/web/20131029195656/
http://storageconference.org/2012/Presentations/M04.Dilger.pdf). IEEE MSST. Archiviert
vom Original (https://giftbot.toolforge.org/deref.fcgi?url=http%3A%2F%2Fstorageconference.
org%2F2012%2FPresentations%2FM04.Dilger.pdf) am 29. Oktober 2013. Abgerufen am
27. Oktober 2013.
21. Datadirect Networks to build world's fastest storage system for Titan, the world's most
powerful supercomputer (https://web.archive.org/web/20131029194043/http://www.multivu.c
om/mnr/60497-datadirect-networks-titan-supercomputer-storage-system-ornl). Archiviert vom
Original (https://giftbot.toolforge.org/deref.fcgi?url=http%3A%2F%2Fwww.multivu.com%2Fm
nr%2F60497-datadirect-networks-titan-supercomputer-storage-system-ornl) am 29. Oktober
2013. Abgerufen am 27. Oktober 2013.
22. EMC Marks Five Years of EMC Centera Innovation and Market Leadership (http://www.emc.
com/about/news/press/us/2007/04182007-5028.htm). EMC. 18. April 2007. Abgerufen am
3. November 2013.
23. Hitachi Content Platform Supports Multiple Petabytes, Billions of Objects (https://web.archiv
e.org/web/20150924113750/http://www.techvalidate.com/portals/hitachi-content-platform-cu
stomers-with-more-than-1pb-of-data-stored). Techvalidate.com. Archiviert vom Original (http
s://giftbot.toolforge.org/deref.fcgi?url=http%3A%2F%2Fwww.techvalidate.com%2Fportals%2
Fhitachi-content-platform-customers-with-more-than-1pb-of-data-stored) am 24. September
2015. Abgerufen am 19. September 2013.
24. Drew Robb: EMC World Continues Focus on Big Data, Cloud and Flash (http://www.infostor.
com/backup-and_recovery/cloud-storage/emc-world-continues-focus-on-big-data-cloud-and-
flash-.html). In: Infostor, 11. Mai 2011. Abgerufen am 19. September 2013. 
25. George Hamilton: In it for the Long Run: EMC's Object Storage Leadership (https://web.archi
ve.org/web/20140315172511/http://www.rethinkstorage.com/in-it-for-the-long-run-emcs-obje
ct-storage-leadership#.UyEzj9yllFI). Archiviert vom Original (https://giftbot.toolforge.org/dere
 f.fcgi?url=http%3A%2F%2Fwww.rethinkstorage.com%2Fin-it-for-the-long-run-emcs-object-st
orage-leadership%23.UyEzj9yllFI) am 15. März 2014. Abgerufen am 15. März 2014.
26. Chris Mellor: Los Alamos National Laboratory likes it, puts Scality's RING on it (https://www.t
heregister.co.uk/2014/07/01/scalitys_ring_goes_faster/), The Register. 1. Juli 2014.
Abgerufen am 26. Januar 2015. 
27. Rich Miller: Facebook Builds Exabyte Data Centers for Cold Storage (http://www.datacenter
knowledge.com/archives/2013/01/18/facebook-builds-new-data-centers-for-cold-
storage/). In: Datacenterknowledge.com, 13. Januar 2013. Abgerufen am 6. November
2013. 
28. Leo Leung: How much data does x store? (https://web.archive.org/web/20140522002448/htt
p://techexpectations.org/2014/05/17/how-much-data-does-x-store/). Techexpectations.org.
17. Mai 2014. Archiviert vom Original (https://giftbot.toolforge.org/deref.fcgi?url=http%3A%2
F%2Ftechexpectations.org%2F2014%2F05%2F17%2Fhow-much-data-does-x-store%2F)
am 22. Mai 2014. Abgerufen am 23. Mai 2014.
29. Leo Leung: Object storage already dominates our days (we just didn't notice) (https://web.arc
hive.org/web/20130929210049/http://blog.oxygencloud.com/2012/01/11/object-storage-alre
ady-dominates/). 11. Januar 2012. Archiviert vom Original (https://giftbot.toolforge.org/deref.f
cgi?url=http%3A%2F%2Fblog.oxygencloud.com%2F2012%2F01%2F11%2Fobject-storage
-already-dominates%2F) am 29. September 2013. Abgerufen am 27. Oktober 2013.
30. Derrick Harris: Amazon S3 goes exponential, now stores 2 trillion objects (http://gigaom.co
m/2013/04/18/amazon-s3-goes-exponential-now-stores-2-trillion-objects/). In: Gigaom,
18. April 2013. Abgerufen am 17. September 2013. 
31. Alex Wilhelm: Microsoft: Azure powers 299M Skype users, 50M Office Web Apps users,
stores 8.5T objects (https://thenextweb.com/microsoft/2013/06/27/microsoft-our-cloud-power
s-hundreds-of-millions/). In: thenextweb.com, 27. Juni 2013. Abgerufen am 18. September
2013. 
32. Fritz Nelson: Microsoft Azure's 44 New Enhancements, 20 Trillion Objects (https://web.archi
ve.org/web/20140506205143/http://www.tomsitpro.com/articles/microsoft-azure-paas-iaas-cl
oud-computing,1-1841.html), Tom's IT Pro. 4. April 2014. Archiviert vom Original (https://giftb
ot.toolforge.org/deref.fcgi?url=http%3A%2F%2Fwww.tomsitpro.com%2Farticles%2Fmicroso
ft-azure-paas-iaas-cloud-computing%2C1-1841.html) am 6. Mai 2014. Abgerufen am
3. September 2014. 
33. Brad Calder: Windows Azure Storage: A Highly Available Cloud Storage Service with
Strong Consistency (http://sigops.org/sosp/sosp11/current/2011-Cascais/printable/11-calder.
pdf). Microsoft. Abgerufen am 6. November 2013.
34. Amita Potnis: IDC MarketScape: Worldwide Object-Based Storage 2019 Vendor
Assessment (https://www.idc.com/getdoc.jsp?containerId=US45354219). In: idc.com. IDC.
Abgerufen am 16. Februar 2020.
35. INCITS 400-2004 (http://www.techstreet.com/cgi-bin/detail?product_id=1204555).
InterNational Committee for Information Technology Standards. Abgerufen am 8. November
2013.
36. INCITS 458-2011 (http://www.techstreet.com/products/1801667). InterNational Committee
for Information Technology Standards. 15. März 2011. Abgerufen am 8. November 2013.
37. OpenStack Foundation: Object Storage API overview (https://docs.openstack.org/developer/
swift/api/object_api_v1_overview.html). In: OpenStack Documentation. Abgerufen am
9. Juni 2017.

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Objektspeicher&oldid=223743858“

Diese Seite wurde zuletzt am 16. Juni 2022 um 13:11 Uhr bearbeitet.
Der Text ist unter der Lizenz „Creative Commons Attribution/Share Alike“ verfügbar; Informationen zu den Urhebern
und zum Lizenzstatus eingebundener Mediendateien (etwa Bilder oder Videos) können im Regelfall durch Anklicken
dieser abgerufen werden. Möglicherweise unterliegen die Inhalte jeweils zusätzlichen Bedingungen. Durch die
Nutzung dieser Website erklären Sie sich mit den Nutzungsbedingungen und der Datenschutzrichtlinie
einverstanden.
Wikipedia® ist eine eingetragene Marke der Wikimedia Foundation Inc.