Objektspeicher

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

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]

Geschichte[Bearbeiten | Quelltext bearbeiten]

Anfänge[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

Abstraktion des Speichers[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

Datenwolke[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

Standards für Geräte mit objektbasiertem Speicher[Bearbeiten | Quelltext bearbeiten]

OSD Version 1[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. ↑ Mike Mesnier: Object-Based Storage. Archiviert vom Original am 14. Mai 2014; abgerufen am 27. Oktober 2013.  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.storagevisions.com
  2. ↑ Yadin Porter De Leon, Tony Piscopo: Object Storage versus Block Storage: Understanding the Technology Differences. Druva.com, abgerufen am 19. Januar 2015.
  3. ↑ Critical Capabilities for Object Storage. Gartner Research, 11. Februar 2014;.
  4. ↑ Garth A. Gibson, Nagle D.: File Server Scaling with Network-Attached Secure Disks. 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. 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). Parallel Data Laboratory, 1. Oktober 1997, abgerufen am 7. November 2013.
  7. ↑ Sanjay Ghemawat, Howard Gobioff: The Google File System. Oktober 2003, abgerufen am 7. November 2013.
  8. ↑ Peter Braam: Lustre: The intergalactic file system. Abgerufen am 17. September 2013.
  9. ↑ OceanStore. Archiviert vom Original 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 19. Februar 2020
  11. ↑ D. Anderson: Object based storage devices: a command set proposal. 1999;.
  12. ↑ Object Based Storage: A Vision, slide presentation, Dave Anderson and Seagate Technology, 13. Oktober 1999
  13. ↑ Fundamentals of garbage collection, Microsoft, .NET fundamentals, 11. Mai 2022, abgerufen am 16. Juni 2022
  14. ↑ George Crump: What Is Hybrid Storage? Abgerufen am 16. Februar 2020.
  15. ↑ a b Peter Vajgel: Needle in a haystack: efficient storage of billions of photos. Abgerufen am 10. September 2013.
  16. ↑ Erik Riedel, Sami Iren: Object Storage and Applications. Februar 2007, abgerufen am 3. November 2013.
  17. ↑ The Seagate Kinetic Open Storage Vision. Seagate, abgerufen am 3. November 2013.
  18. ↑ Sean Gallagher: 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. 4. November 2008, abgerufen am 8. November 2013.
  20. ↑ Andreas Dilger: Lustre Future Development. IEEE MSST, archiviert vom Original 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. Archiviert vom Original am 29. Oktober 2013; abgerufen am 27. Oktober 2013.
  22. ↑ EMC Marks Five Years of EMC Centera Innovation and Market Leadership. EMC, 18. April 2007, abgerufen am 3. November 2013.
  23. ↑ Hitachi Content Platform Supports Multiple Petabytes, Billions of Objects. Techvalidate.com, archiviert vom Original am 24. September 2015; abgerufen am 19. September 2013.
  24. ↑ Drew Robb: EMC World Continues Focus on Big Data, Cloud and Flash In: Infostor, 11. Mai 2011. Abgerufen am 19. September 2013 
  25. ↑ George Hamilton: In it for the Long Run: EMC's Object Storage Leadership. Archiviert vom Original 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, The Register, 1. Juli 2014. Abgerufen am 26. Januar 2015 
  27. ↑ Rich Miller: Facebook Builds Exabyte 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? Techexpectations.org, 17. Mai 2014, archiviert vom Original am 22. Mai 2014; abgerufen am 23. Mai 2014.
  29. ↑ Leo Leung: Object storage already dominates our days (we just didn't notice). 11. Januar 2012, archiviert vom Original am 29. September 2013; abgerufen am 27. Oktober 2013.
  30. ↑ Derrick Harris: 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 In: thenextweb.com, 27. Juni 2013. Abgerufen am 18. September 2013 
  32. ↑ Fritz Nelson: Microsoft Azure's 44 New Enhancements, 20 Trillion Objects (Memento des Originals vom 6. Mai 2014 im Internet Archive), Tom's IT Pro, 4. April 2014. Abgerufen am 3. September 2014 
  33. ↑ Brad Calder: Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency. Microsoft, abgerufen am 6. November 2013.
  34. ↑ Amita Potnis: IDC MarketScape: Worldwide Object-Based Storage 2019 Vendor Assessment. In: idc.com. IDC, abgerufen am 16. Februar 2020.
  35. ↑ INCITS 400-2004. InterNational Committee for Information Technology Standards, abgerufen am 8. November 2013.
  36. ↑ INCITS 458-2011. InterNational Committee for Information Technology Standards, 15. März 2011, abgerufen am 8. November 2013.
  37. ↑ OpenStack Foundation: Object Storage API overview. In: OpenStack Documentation. Abgerufen am 9. Juni 2017.
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Objektspeicher&oldid=243707344“