wake-up-neo.net

Unterschied zwischen Objektspeicher und Dateiablage

Könnte jemand erklären, was der Unterschied zwischen Objektspeicherung und Dateispeicherung ist?

Ich habe über Object Storage in wiki gelesen und auch http://www.Dell.com/downloads/global/products/pvaul/de/object-storage-overview.pdf gelesen und auch gelesen amazons docs (S3), openstack swift usw. Aber könnte mir jemand ein Beispiel geben, um es besser zu verstehen?

Der Unterschied ist nur, dass für 'Objektspeicher' Objekte mehr Metadaten hinzugefügt werden?

Zum Beispiel, wie man ein Bild wie ein Objekt mit einer Programmiersprache (zum Beispiel Python) speichert?

Vielen Dank.

21
Sever

IMO, Objektspeicher hat nichts mit Skalierung zu tun, weil jemand eine FS erstellen könnte, die eine große Anzahl von Dateien sogar in einem einzigen Verzeichnis speichern kann.

Es geht auch nicht um die Zugriffsmethoden. Der HTTP-Zugriff auf Daten in Dateisystemen war in vielen bekannten NAS Systemen verfügbar.

Speicher/Zugriff über OID ist eine Möglichkeit, Daten zu behandeln, ohne sich um die Benennung zu kümmern. Es könnte auch für Dateien gemacht werden. Ich glaube, dass es eine NFS-Protokollerweiterung gibt, die dies erlaubt.

Ich würde folgendes zusammenfassen: Die Objektspeicherung ist eine (neue/andere) objektorientierte Denkweise für Daten, deren Zugriff und Verwaltung.

Denken Sie über diese Punkte nach:

Was sind heute Schnappschüsse? Sie sind Zeitpunktkopien eines Bandes. Wenn ein Schnappschuss erstellt wird, werden auch alle Dateien auf dem Volume gefangen. Ob alle es mögen oder nicht, ob alle es brauchen oder nicht. Viel Speicherplatz kann für einen vollständigen Volume-Snapshot verwendet werden (verschwendet?), Während nur wenige Dateien gerastet werden mussten.

In einem Objektspeichersystem werden selten Momentaufnahmen von Datenträgern angezeigt, Objekte werden automatisch, möglicherweise automatisch, aufgezeichnet. Dies ist die Objektversionierung. Alle Objekte müssen nicht versioniert werden. Jedes einzelne Objekt kann feststellen, ob es versioniert ist.

Wie werden Dateien/Volumes vor einer Katastrophe geschützt? Normalerweise werden in einem Disaster Recovery-Setup (DR) vollständige Volumes/Volume-Sets für die Replikation an einem DR-Standort eingerichtet. Auch hier spielt es keine Rolle, ob einzelne Dateien repliziert werden sollen oder nicht. Die Einheit des Katastrophenschutzes ist das Volume. Dateien sind kleine Fische.

In einem Objektspeichersystem ist DR nicht volumenzentrisch. Objektmetadaten können entscheiden, wie viele Kopien vorhanden sein sollen und wo (Geo-Standorte/Fehlerdomänen).

Ähnlich für andere Funktionen:

  1. Tiering - Objekte, die basierend auf ihren Metadaten in Speicherebenen/-klassen abgelegt werden, unabhängig von anderen nicht verknüpften Objekten.

  2. Leben - Objekte bewegen sich zwischen den Ebenen, ändern die Anzahl der Kopien usw. einzeln und nicht als Gruppe.

  3. Authentifizierung - Einzelne Objekte können bei Bedarf von verschiedenen Authentifizierungsdomänen authentifiziert werden.

Wie Sie sehen, besteht die Änderung im Denken darin, dass sich in einem Objektspeicher alles um ein Objekt dreht.

Im Gegensatz dazu ist das traditionelle Denken und Verwalten und Zugreifen auf größere Container wie Datenträger (die Dateien enthalten) kein Objektspeicher.

Die oben genannten Merkmale und ihre Objektorientierung passen gut zu den Anforderungen unstrukturierter Daten und damit zu den Interessen.

Wenn ein Speichersystem objekt- oder dateizentriert anstatt volumenzentrisch ist (unabhängig vom Zugriffsprotokoll oder der Skala), handelt es sich um ein Objektspeichersystem.

15

Es gibt einige grundlegende Unterschiede zwischen der Dateispeicherung und der Objektspeicherung. 

Dateispeicherung präsentiert sich als Dateisystemhierarchie mit Verzeichnissen, Unterverzeichnissen und Dateien. Es ist großartig und funktioniert wunderbar, wenn die Anzahl der Dateien nicht sehr groß ist. Es funktioniert auch gut, wenn Sie genau wissen, wo Ihre Dateien gespeichert sind.

Objektspeicher dagegen bietet sich typischerweise über. eine RESTful-API. Es gibt kein Konzept eines Dateisystems. Stattdessen speichert eine Anwendung ein Objekt (Dateien + zusätzliche Metadaten) über den Objektspeicher. Die PUT-API und der Objektspeicher würden das Objekt irgendwo im System speichern. Die Objektspeicherplattform würde der Anwendung einen eindeutigen Schlüssel (analog zu einem Valet-Ticket) für das Objekt geben, das die Anwendung in der Anwendungsdatenbank speichern würde. Wenn eine Anwendung das Objekt abrufen wollte, muss sie lediglich den Schlüssel als Teil der GET-API angeben, und das Objekt wird vom Objektspeicher abgerufen.

Hoffe das ist jetzt klar.

11
J Storage

Offenlegung - Ich arbeite für einen Anbieter (NetApp), der sowohl große Dateisystem- als auch Objektspeicherplattformen entwickelt und vertreibt. Ich werde versuchen, diese Implementierung so neutral wie möglich zu halten, aber meine kognitiven Verzerrungen können meine Antwort unbewusst beeinflussen.

Es gibt viele Unterschiede, sowohl was den Zugang, die Programmierbarkeit als auch die Implementierung betrifft. Da dies jedoch wahrscheinlich eher von Programmierern als von Infrastruktur- oder Speicherleuten gelesen wird, werde ich mich hier auf diesen Aspekt konzentrieren.

Der Hauptunterschied aus externer Sicht/Programmiersicht ist, dass ein Objekt in einem Objektspeicher als vollständige Einheit erstellt oder gelöscht oder aktualisiert wird. Sie können keine Daten an ein Objekt anhängen und einen Teil eines Objekts nicht aktualisieren Objekt "an Ort und Stelle", Sie können es jedoch unter Beibehaltung der gleichen Objekt-ID ersetzen. Das Erstellen, Lesen, Aktualisieren und Löschen von Objekten erfolgt in der Regel über relativ unkomplizierte APIs, die fast immer auf REST-basiert oder auf REST basieren. Dies legt nahe, dass das Geschäft eine programmierbare Ressource oder möglicherweise ein Multi-Tenant-Remote-Service ist. Während bei den meisten Objektspeichern die Unterstützung des Bytebereichs innerhalb eines Objekts unterstützt wird, waren Objektspeichern in der Regel dafür ausgelegt, mit ganzen Objekten zu arbeiten. Beispiele für Objektspeicher-APIs sind die von Amazon S3 (dem Standardstandard für den Objektspeicherzugriff), OpenStack Swift und der API des Azure Blob-Dienstes REST verwendeten. Die Back-End-Implementierungen hinter diesen APIs zu beschreiben, wäre ein Buch für sich.

Andererseits haben Dateien in einem Dateisystem eine breitere Palette von Funktionen, die auf sie angewendet werden können, einschließlich Anhängen von Daten und Aktualisieren von Daten. Das Programmiermodell ist komplexer als ein Objektspeicher und wird jetzt fast immer programmgesteuert über eine "POSIX" -Schnittstelle aufgerufen. Es wird im Allgemeinen versucht, CPU und Speicher möglichst effizient zu nutzen, und ermutigt zu der Annahme, dass das Dateisystem eine private lokale Ressource ist . NFS und SMB ermöglichen die Bereitstellung eines Dateisystems als multi-mandantenfähige Ressource. Diese werden jedoch häufig von Programmierern mit Misstrauen behandelt, da sie manchmal trotz ihres Dateisystems geringfügige Unterschiede im Vergleich zu "lokalen" Dateisystemen aufweisen volle Unterstützung für POSIX-Semantik. Um Dateien in einem lokalen Dateisystem zu aktualisieren, verwenden Sie wahrscheinlich APIs wie https://www.classes.cs.uchicago.edu/archive/2017/winter/51081-1/LabFAQ/lab2/fileio.html oder https://msdn.Microsoft.com/en-us/library/mt794711(v=vs.85).aspx . Sprechen über die relativen Vorzüge von Dateisystemimplementierungen, z. NTFS vs. BTRFS vs. XFS vs. WAFL vs. ZFS neigt dazu, zu einem Religionskrieg zu führen, der selten etwas wert ist. Wenn Sie mir ein Bier kaufen, teile ich Ihnen gerne meine Ansichten mit.

Wenn Sie aus einer Use-Case-Sicht eine große Anzahl von Fotos, Videos oder binären Build-Artefakten behalten möchten, ist ein Objektspeicher oft eine gute Wahl. Wenn Sie andererseits Daten dauerhaft in einem Binärbaum speichern und diese Daten auf dem Speichermedium aktualisieren möchten, funktioniert ein Objektspeicher einfach nicht, und Sie wären mit einem Dateisystem viel besser dran (Sie könnten auch Verwenden Sie dafür rohe Blockiergeräte, aber ich habe seit den frühen 90ern niemanden gesehen.

Die anderen großen Unterschiede sind, dass Dateisysteme so konzipiert sind, dass sie stark konsistent sind und normalerweise über Netzwerke mit niedriger bis mittlerer Latenzzeit (50 Mikrosekunden - 50 Millisekunden) zugegriffen werden, wohingegen Objektspeicher häufig konsistent sind und über eine gemeinsam genutzte nichts miteinander verbundene Infrastruktur verteilt sind Breitbandnetze mit hoher Latenzzeit und große Zeit bis zum ersten Byte können manchmal in Vielfachen von ganzen Sekunden gemessen werden. Wenn Sie viele kleine (4K - 16K) Zufallslesevorgänge aus einem Objektspeicher ausführen, kann dies zu Frustration und Leistungsproblemen führen.

Der andere Hauptvorteil eines Objektspeichers im Vergleich zu einem Dateisystem besteht darin, dass Sie ziemlich sicher sein können, dass alles, was Sie in einem Objektspeicher ablegen, dort verbleibt, bis Sie es erneut anfordern, und dass der Speicherplatz nie ausgeht, solange Sie weiter zahlen für die monatlichen Gebühren. Diese Ressourcen werden im Allgemeinen in großem Umfang mit integrierter Replizierung, Versionskontrolle, automatisierter Wiederherstellung usw. ausgeführt. Wenn Sie nach einem Hurricane Harvey-Desaster stolpern, werden die Daten verschwinden (selbst dann haben Sie die Möglichkeit, eine weitere Kopie an einem anderen Speicherort zu erstellen). Bei einem Dateisystem, das Sie oder Ihre Mitarbeiter vor Ort erwarten, müssen Sie hoffen, dass alles gesichert wird und nicht versehentlich voll wird und alles zum Erliegen kommt, wenn Sie Ihre Daten nicht mehr aktualisieren können.Ich habe mich bemüht zu beschwichtigen, aber um die Verwirrung zu verstärken, werden die Wörter "Dateisystem" und "Objektspeicher" auf Dinge angewendet, die nicht den oben beschriebenen Beschreibungen entsprechen. Das NFS-Dateisystem ist das eigentlich nicht Ein Dateisystem ist eine Möglichkeit, die Posix-Speicher-APIs über Remoteprozeduraufrufe zu implementieren. Das VSAN von VMware speichert seine Daten in etwas, das sie als "Objektspeicher" bezeichnen, wodurch Aktualisierungen der Images der virtuellen Maschinen mit hoher Geschwindigkeit erfolgen können.

I've tried to be conscise, but to add to the confusion the words "filesystem" and "object store” get applied to things which are nothing like the descriptions I’ve used above, e.g. NFS the Network file system isn’t actually a filesystem, its a way of implementing the posix storage API’s via remote procedure calls, and VMware’s VSAN stores its data in something they refer to as an "object store" which allows high speed in place updates of the virtual machine images.

5
Crankbird

Die einfache Antwort ist, dass auf Speichersysteme oder Dienste, auf die mit einem Objekt zugegriffen wird, APIs und andere Objektzugriffsmethoden zum Speichern, Abrufen und Nachschlagen von Daten im Gegensatz zu herkömmlichen Dateien oder NAS verwendet werden. Zum Beispiel greifen Sie mit NFS (Network File System) oder CIFS (z. B. Windows-Dateifreigabe) aka SMB oder SAMBA auf Speicher zu, wenn die Datei einen Namen/Handle mit den vom Dateisystem bestimmten Metadaten hat . 

Die Metadaten enthalten Informationen zu Erstellungs-, Zugriffs-, Änderungs- und anderen Datumsangaben, Berechtigungen, Sicherheit, Anwendungs- oder Dateityp oder anderen Attributen. Dateien sind durch das Dateisystem hinsichtlich ihrer Größe sowie der Anzahl der Dateien pro Dateisystem begrenzt. Ebenso sind Dateisysteme durch ihre Gesamt- oder Aggregatgröße in Bezug auf die Speicherplatzkapazität und die Anzahl der Dateien im Dateisystem begrenzt.

Der Objektzugriff unterscheidet sich dahingehend, dass Datei- oder NAS - Frontend oder Gateways oder Plugins für viele Lösungen oder Services verfügbar sind. Der primäre Zugriff erfolgt jedoch über eine API, bei der ein Objekt eine beliebige Größe haben kann (bis zu einer maximalen Größe) Objektsystem) zusammen mit Metadaten variabler Größe (abhängig von der Objektsystem-/Dienstimplementierung). Bei den meisten Objektspeichersystemen/-diensten können Sie eine beliebige Anzahl von benutzerdefinierten Metadaten oder GBytes für einige Kbytes angeben. Wofür würden Sie GBytes an Metadaten verwenden? Wie wäre es zusätzlich zu normalen Informationen, Hinzufügen weiterer Daten für Richtlinien, Verwaltung, wo sich andere Kopien befinden, Miniaturansichten oder kleine Vorschauen von Videos, Audio usw.

Beispiele für APIs oder Schnittstellen für den Objektzugriff umfassen einfache Speicherservices (S3) von Amazon Web Services (AWS) oder andere auf HTTP und REST basierende SNIA CDMI. Verschiedene Lösungen unterstützen auch den Zugriff auf IOS (z. B. iPhone/iPad), SOAP, Torrent, WebDav, JSON, XAM und andere sowie NFS/CIFS. Darüber hinaus unterstützen viele der Objektspeichersysteme oder -dienste unter anderem programmatische Bindungen für Python. Mit den APIs können Sie im Wesentlichen einen Stream öffnen und dann Liste, Funktionen und andere von der API/dem System unterstützte Funktionen abrufen oder einfügen, um zu bestimmen, wie Sie diesen verwenden.

Zum Beispiel verwende ich sowohl Rackspace Cloud-Dateien als auch Amazon S3 (zusätzlich zu EBS und Glacier) zum Sichern, Speichern und Archivieren von Daten. Ich kann auf die gespeicherten Objekte über einen Webbrowser oder Tools zugreifen, einschließlich Jungle Disk (JD), mit der ich Dateien sichere und synchronisiere. JD übernimmt für mich die Objektverwaltung und verschiebt Daten sowohl in Rackspace als auch bei Amazon. Wenn ich geneigt wäre, könnte ich auch mit den APIs programmieren und dann direkt auf eine dieser Websites zugreifen, die meine Sicherheitsberechtigungen bereitstellt, um mit meinen gespeicherten Objekten zu arbeiten.

Hier ist ein Link zu Object und Cloud Storage Primer aus einer Sitzung, die ich letztes Jahr in Holland durchgeführt habe und einige einfache Beispiele für Objekte und Zugriff enthält . http://storageio.com/DownloadItems/Nijkerk_Nov2012/SIO_IndustryTrends_CloudObjectStorage.pdf)

Mit der programmatischen Bindung würden Sie Ihre Datenstrukturen oder Objekte in Ihrem Programm definieren und dann die APIs oder Aufrufe zum Speichern, Abrufen, Auflisten von Daten, Metadatenzugriff usw. verwenden. Wenn ein bestimmtes Objektspeichersystem, eine Software oder ein Dienst vorhanden ist Sie suchen mit oder arbeiten mit oder müssen wissen, wie sie programmieren sollen, besuchen Sie ihre Website und Sie sollten die SDK- oder API-Informationen mit Beispielen finden. Wenn Sie mit Objekten einen anfänglichen Bucket oder Container in einem Service oder mit einem Produkt/System erstellen, erstellen und speichern Sie einfach weitere Objekte, während Sie gehen.

Hier ist ein Link als Beispiel zu AWS S3-API/-Programmierung: http://docs.aws.Amazon.com/AmazonS3/latest/API/IntroductionAPI.html

In der Theorie wird von Objektspeichersystemen die Rede sein, die über eine unbegrenzte Anzahl von Objekten oder Objektgrößen verfügen. In Wirklichkeit sind die meisten Systeme, Lösungen, Software oder Dienste auf das beschränkt, was sie entweder getestet haben oder aktuell unterstützen, was Milliarden von Objekten sein kann Objektgrößen von 5 GByte oder größer. Achten Sie auf die Grenzen bestimmter Dienste oder Produkte hinsichtlich der tatsächlich getesteten, unterstützten, was architektonisch möglich ist oder was auf Webex oder PowerPoint implementiert ist.

Auch hier sind Service und Produkt/Service/Software abhängig von der Anzahl der Objekte, der Größe der Objekte, der Größe der Metadaten und der Datenmenge, die über ihre APIs ein-/ausgefahren werden können. Grundsätzlich kann jedoch davon ausgegangen werden, dass die Objektspeicherung (je nach Implementierung) weitaus skalierbarer sein kann als Dateisysteme (ohne Verwendung des globalen Namensraums, des Verbunds, der Dateivirtualisierung oder anderer Techniken).

Weitere Informationen zu Cloud- und Objektspeicherung finden Sie in meinem Buch "Cloud- und virtuelle Datenspeicherungsnetzwerke (CRC Press)", das von Intel empfohlen wird.

Ich werde bald mehr verwandtes Material zu www.objectstorage.us hinzufügen.

Prost gs

3
Gee Schulz

Objektspeicher = Speicher blockieren + Reichhaltige Metadaten - Dateihierarchie

Block Storage verwendet ein Dateisystem, um zu zeigen, wo Inhalte gespeichert werden. Object Storage verwendet einen Identifikator, um auf Inhalt und seinen Kontext zu verweisen. Dies ist mein Verständnis des Lesens von Content-Adressierung vs. Standort-Adressierung .

Block Storage benötigt ein Dateisystem und eine Strukturierung, so dass bei größeren Dateien das System mehr Aufwand verursacht. Der Objektspeicher hat eine Menge Kontext zu der Datei und benötigt keine Dateihierarchie. Die Erklärung auf Seite 7 des Dell Paper zeigt dies eindeutig .. Was mich beunruhigt hat, war, dass es auf der Festplatte selbst nicht erklärt wird ... Ich fand heraus, dass eine Festplatte selbst immer einen Block-Speichermechanismus verwendet (obwohl das der Fall ist) scheint sich zu ändern) (obwohl sich das zu ändern scheint)

einige andere Einsichten finden Sie hier

2
Guy Forssman

Oh, ich wünschte, ich könnte ein paar Antworten runterstimmen und andere mit einem Konto abstimmen.

Derjenige mit den meisten Stimmen, wie in diesem Artikel, erklärt nicht einmal etwas über die Unterschiede.

Es gibt einige grundlegende Unterschiede zwischen der Dateispeicherung und der Objektspeicherung.

Dateispeicherung präsentiert sich als Dateisystemhierarchie mit Verzeichnissen, Unterverzeichnissen und Dateien. Es ist großartig und funktioniert wunderbar, wenn die Anzahl der Dateien nicht sehr groß ist. Es funktioniert auch gut, wenn Sie genau wissen, wo Ihre Dateien gespeichert sind.

Objektspeicher dagegen bietet sich typischerweise über. eine RESTful-API. Es gibt kein Konzept eines Dateisystems. Stattdessen speichert eine Anwendung ein Objekt (Dateien + zusätzliche Metadaten) über den Objektspeicher. Die PUT-API und der Objektspeicher würden das Objekt irgendwo im System speichern. Die Objektspeicherplattform würde der Anwendung einen eindeutigen Schlüssel (analog zu einem Valet-Ticket) für das Objekt geben, das die Anwendung in der Anwendungsdatenbank speichern würde. Wenn eine Anwendung das Objekt abrufen wollte, muss sie lediglich den Schlüssel als Teil der GET-API angeben, und das Objekt wird vom Objektspeicher abgerufen.

Hoffe das ist jetzt klar.

Dies erklärte einen großen Teil davon; Sie haben aber über die Metadaten gestritten. Das Folgende ist aus dem, was ich in den letzten zwei Tagen gelesen habe, und da dies nicht behoben wurde, werde ich hier posten.

Die Objektspeicherung hat keinen Sinn für Ordner oder irgendeine Organisationsstruktur, die die Organisation eines Menschen vereinfacht. Dateispeicherung verfügt natürlich über alle Ordner, die es einem Menschen so einfach machen, zu ordnen und durchzublättern ... In einer Serverumgebung mit der Anzahl der Dateien in einer astronomischen Skala sind Ordner nur eine Verschwendung von Platz und Zeit.

Datenbanken, die du sagst? Nun, er spricht nicht über den Objektspeicher selbst. Er sagt, dass Ihr http-Dienst (PHP, Webmail usw.) die eindeutige ID in seiner Datenbank hat, um auf eine Datei zu verweisen, die möglicherweise einen vom Menschen erkennbaren Namen hat.

Metadaten, wo ist diese Datei gespeichert? Dafür sind die Metadaten gedacht. Ihre einzelne Datei wird in mehrere kleine Teile aufgeteilt und über geografische Standorte, Server und Festplatten verteilt. Diese kleinen Teile enthalten auch mehr Daten, sie enthalten Paritätsinformationen für die anderen Daten oder sogar eine vollständige Vervielfältigung.

Die Metadaten werden verwendet, um alle Daten dieser Datei über verschiedene geografische Standorte, Rechenzentren, Server und Festplatten zu lokalisieren und zerstörte Teile nach einem Hardwarefehler wiederherzustellen. Dies geschieht automatisch. Diese Stücke werden sogar fließend bewegt, um eine bessere Verteilung zu erreichen. Es wird sogar ein Stück, das weg ist, neu erstellt und auf einer neuen guten Festplatte gespeichert.

Dies ist vielleicht eine einfache Erklärung. aber ich denke, es könnte Ihnen helfen, besser zu verstehen. Ich glaube, dass Dateispeicherung dasselbe mit den Metadaten tun kann. Dateispeicherung ist Speicher, den Sie als Benutzer organisieren können (Ordner, Hierarchie usw.), während der Objektspeicher keine Hierarchie, keine Ordner, sondern nur einen flachen Speichercontainer hat.

1
Roland

Die meisten Unternehmen mit objektbasierten Lösungen verfügen über eine Mischung aus Block-, Datei- und Objektspeicher, die je nach Leistung und Kosten ausgewählt wird.

Aus einer Use Case-Perspektive: 

Letztendlich wurde Objektspeicherung geschaffen, um unstrukturierte Daten zu adressieren, die explosionsartig anwachsen, viel schneller als strukturierte Daten.

Wenn es sich bei einer Datenbank beispielsweise um strukturierte Daten handelt, wäre unstrukturiert ein Word-Dokument oder eine PDF-Datei. 

Wie durchsuchen Sie 1 Milliarde PDFs in einem Dateisystem? (Wenn es überhaupt so viele speichern könnte).

Wie schnell könnten Sie nur die Metadaten von 1 Milliarde Dateien suchen?

Die Objektspeicherung wird derzeit eher für Langzeit- oder Archivierungszwecke, für eine kostengünstige und tiefe Speicherung verwendet, die detailliertere Informationen über die Daten enthält. Diese Metadaten werden sehr leistungsfähig, wenn sehr große Datensätze durchsucht oder durchsucht werden. Manchmal erhalten Sie aus den Metadaten das, was Sie benötigen, ohne auf die Daten selbst zuzugreifen. Objektspeicherlösungen können normalerweise automatisch mit dem integrierten geografischen Failover repliziert werden.

Das Problem ist, dass die Anwendung neu geschrieben werden muss, um Objektzugriffsmethoden anstelle der Dateiergelhierarchie zu verwenden (was aus Sicht der Anwendungsentwickler einfacher ist). Es ist wirklich eine Änderung in der Philosophie der Datenspeicherung und das Speichern von umsetzbareren Informationen zu diesen Daten aus Sicht des Managements sowie der Verwendung.

Ein schnelles Beispiel könnte ein MRI-Scanbild sein. Im Dateisystem haben Sie Besitzer/Erstellungsdatum, aber sonst nicht viel. Wenn es sich um ein Objekt handelt, könnten alle Informationen, die das MRI umgeben, in Metadaten gespeichert werden, z. B. Patientenname, Lage des MRI-Zentrums, anfragender Dr., Versicherungsträger usw.

Block/File eignen sich besser für den lokalen Zugriff oder OTLP, wenn Leistung wichtiger ist als Aufbewahrung und Kosten.

Beispielsweise möchten Sie nicht Minuten warten, bis ein Word-Dokument geöffnet wird. Sie könnten jedoch einige Minuten warten, bis ein Data Mining/Business Intelligence-Prozess abgeschlossen ist. 

Ein anderes Beispiel wäre eine legale Suche, bei der Sie alles von vor 5 Jahren bis zur Gegenwart suchen müssen. Wenn Sie Aufbewahrungsrichtlinien verwenden, um den aktiven Datensatz und die Kosten zu senken, wie würden Sie das sogar tun, ohne von Band wiederherstellen zu müssen?

Die Objektspeicherung ist eine großartige Lösung, um langfristige Archivierungsmethoden wie Band zu ersetzen. 

Das Einrichten von Replikation und Failover für Block und Datei kann im Unternehmen sehr teuer werden und erfordert normalerweise sehr teure Software und Services.

Hinweis: Auf der unteren Ebene erfolgt der Zugriff auf den Objektspeicher über die RESTful-API. Dies ist mehr eine Webanforderung als ein Zugriff auf eine Datei am Ende eines Pfads.

1
Jeff Pitoniak

Dieser Link erklärt die Unterschiede zwischen den beiden: http://www.Dell.com/downloads/global/products/pvaul/de/object-storage-overview.pdf

0
Wes Johnson

Ich denke, das Whitepaper erklärt die Idee der Objektspeicherung ziemlich gut. Ich kenne keine Standardmethode zur Verwendung von Objektspeichergeräten (im Sinne eines SCSI-OSD) von einer Benutzeranwendung aus. 

Objektspeicher wird in einigen großen Speicherprodukten wie den Speichergeräten von Panasas verwendet. Diese Appliances exportieren dann ein Dateisystem für den Endbenutzer. Ich kann zu Recht sagen, dass die T10-OSD-Idee nie wirklich an Bedeutung gewonnen hat. 

Verwandte Ideen zum OSD-Standard finden sich in Cloud-Speichersystemen wie S3 und RADOS

0
dmeister

Tatsächlich können Sie einen Bucket/Container mounten und von Linux aus auf die Objekte oder Unterordner (und ihre Objekte) zugreifen. Zum Beispiel habe ich auf Ubuntu s3fs installiert, dass ich einen Mountpunkt für einen meiner S3-Buckets eingerichtet habe und reguläre cp, ls und andere Funktionen ausführen kann, als wäre es ein anderes Dateisystem. Der Schlüssel ist, das Software-Tool zu bekommen, von dem es eine Fülle gibt, mit der Sie einen Container/Eimer zuordnen und als Einhängepunkt darstellen können. Es gibt auch Software-Tools, mit denen Sie zusätzlich zu NAS als iSCSI auf S3 und andere Buckets/Container zugreifen können.

0
Gee Schulz

Hier ist ein guter Artikel, den es zu lesen gilt: https://cloudian.com/blog/object-storage-vs-file-storage/ Zitiert aus dem Artikel:

Zunächst einmal überwindet der Objektspeicher viele der Einschränkungen, mit denen der Dateispeicher konfrontiert ist. Stellen Sie sich die Dateispeicherung als Lager vor. Wenn Sie zum ersten Mal eine Schachtel mit Dateien darin ablegen, haben Sie anscheinend viel Platz. Wenn Ihre Datenanforderungen jedoch steigen, füllen Sie das Warehouse vollständig aus, bevor Sie es bemerken. Die Objektlagerung hingegen ist wie das Lagerhaus, nur ohne Dach. Sie können unendlich viele Daten hinzufügen - der Himmel ist die Grenze. Wenn Sie in erster Linie kleinere oder einzelne Dateien abrufen, glänzt der Dateispeicher mit Leistung, insbesondere bei relativ geringen Datenmengen. Sobald Sie mit dem Skalieren beginnen, fragen Sie sich möglicherweise: "Wie finde ich die benötigte Datei?" eine andere Analogie, aber ertrage es mit mir!). Wenn Sie Ihr Auto in eine kleine Menge ziehen, wissen Sie genau, wo sich Ihr Auto befindet. Stellen Sie sich jedoch vor, das Los wäre tausendmal größer - es wäre schwieriger, Ihr Auto zu finden, oder? Da der Objektspeicher anpassbare Metadaten enthält und sich alle Objekte in einem flachen Adressraum befinden, ähnelt dies der Übergabe Ihrer Schlüssel an einen Parkservice. Ihr Auto wird irgendwo aufbewahrt und wenn Sie es brauchen, wird der Parkservice das Auto für Sie besorgen. Es kann etwas länger dauern, bis Sie Ihr Auto gefunden haben, aber Sie müssen sich keine Gedanken darüber machen, wie Sie danach suchen.

0
chuck