IBM Cloud Docs
Daten hochladen

Daten hochladen

Nachdem Sie Ihren Speicher in Buckets organisiert haben, können Sie einige Objekte hinzufügen, indem Sie Daten hochladen.

Abhängig davon, wie Sie den Speicher nutzen möchten, gibt es verschiedene Möglichkeiten, um Daten ins System einzulesen. Ein Data-Scientist verfügt über einige große Dateien, die zu Analysezwecken verwendet werden. Ein Systemadministrator muss sicherstellen, dass die Datenbanksicherungen mit den lokalen Dateien synchronisiert bleiben und ein Entwickler schreibt Software, mit der Millionen von Dateien gelesen und geschrieben werden sollen. Für jedes dieser Szenarios gibt es eine optimale Methode zur Datenaufnahme.

Einige Anwendungen können einen Benutzer oder eine Service-ID auf das ausschließliche Hochladen von Daten beschränken, ohne auf das Lesen von Daten in einem Bucket zugreifen zu müssen. Dies ist über die IAM-Rolle des Objektschreibprogramms möglich.

Verwendung der Konsole

Normalerweise stellt die webbasierte Konsole nicht die am häufigsten genutzte Methode zur Verwendung von Object Storage dar. Objekte sind auf eine Größe von 200 MB beschränkt und der Dateiname und der Schlüssel sind identisch. Sie können mehrere Objekte gleichzeitig hochladen. Sofern der verwendete Browser mehrere Threads unterstützt, kann jedes Objekt in mehreren Teilen parallel hochgeladen werden. Die Unterstützung für größere Objekte und die (abhängig von bestimmten Netzfaktoren) verbesserte Leistung wird durch die Aspera-Hochgeschwindigkeitsübertragung bereitgestellt.

Kompatibles Tool verwenden

Bestimmte Benutzer möchten ein eigenständiges Dienstprogramm verwenden, um mit ihrem Speicher zu interagieren. Da die Cloud Object Storage-API die am häufigsten verwendete Gruppe von S3-API-Operationen unterstützt, können viele S3-kompatible Tools eine Verbindung zu Object Storage auch mithilfe von HMAC-Berechtigungsnachweisen herstellen.

Die Beispiele umfassen Dateiexplorer wie Cyberduck oder Transmit, Sicherungsdienstprogramme wie Cloudberry und Duplicati, Befehlszeilendienstprogramme wie s3cmd oder MinIO Client und zahlreiche andere Tools. Sie können auch im IBM Cloud Katalog nach Diensten von Drittanbietern suchen, die es Ihnen ermöglichen, Daten nach Cloud Object Storage zu verschieben, z. B. Lyve Data Transfer Services.

API verwenden

Die meisten programmgesteuerten Object Storage-Anwendungen verwenden ein SDK (z. B. für Java, Node.js oder Python) oder die Cloud Object Storage-API. Objekte werden normalerweise in mehreren Teilen hochgeladen. Dabei werden die Größe der Teile und ihre Anzahl mithilfe einer Klasse des Übertragungsmanagers konfiguriert.

Bedingte Anforderungen

Wenn Sie eine Anforderung zum Lesen oder Schreiben von Daten absetzen, können Sie Bedingungen für diese Anforderung festlegen, um unnötige Operationen zu vermeiden. Dies wird durch die folgenden voraussetzungsvollen HTTP Kopfzeilen erreicht: If-Match, If-None-Match, If-Modified-Since, und If-Unmodified-Since.

Es ist im Allgemeinen vorzuziehen, If-Match zu verwenden, da die Granularität des Werts Last-Modified nur in Sekunden beträgt und möglicherweise nicht ausreicht, um Konkurrenzsituationen in einigen Anwendungen zu verhindern.

If-Match verwenden

Bei einer Objekt PUT-, HEAD-oder GET-Anforderung prüft der If-Match Header, ob ein bereitgestellter Etag (MD5-Hashwert des Objektinhalts) mit dem angegebenen Etag-Wert übereinstimmt. Wenn dieser Wert übereinstimmt, wird die Operation fortgesetzt. Wenn die Übereinstimmung fehlschlägt, gibt das System den Fehler 412 Precondition Failed zurück.

If-Match wird am häufigsten mit Methoden zur Statusänderung (z. B. POST, PUT, DELETE) verwendet, um versehentliche Überschreibungen zu verhindern, wenn mehrere Benutzeragenten parallel auf derselben Ressource arbeiten (d. h., um das Problem "verlorene Aktualisierung" zu verhindern).

If-None-Match verwenden

Bei einer Objekt PUT-, HEAD-oder GET-Anforderung prüft der If-None-Match Header, ob ein bereitgestellter Etag (MD5-Hashwert des Objektinhalts) mit dem angegebenen Etag-Wert übereinstimmt. Wenn dieser Wert nicht übereinstimmt, wird die Operation fortgesetzt. Wenn die Übereinstimmung erfolgreich ist, gibt das System einen 412 Precondition Failed-Fehler in einem PUT und einen 304 Not Modified in GET oder HEAD zurück.

If-None-Match wird hauptsächlich in bedingten GET-Anforderungen verwendet, um effiziente Aktualisierungen zwischengespeicherter Informationen mit minimalem Transaktionsaufwand zu ermöglichen. Wenn ein Client eine oder mehrere gespeicherte Antworten mit Entitätstags aktualisieren möchte, sollte der Client beim Erstellen einer GET-Anforderung ein Headerfeld "If-None-Match" generieren, das eine Liste dieser Entitätstags enthält. Dies ermöglicht es den Empfängerservern, eine Antwort 304 (Nicht geändert) zu senden, um anzuzeigen, wenn eine dieser gespeicherten Antworten der ausgewählten Darstellung entspricht.

If-Modified-Since verwenden

Bei einer HEAD-oder GET-Objektanforderung prüft der If-Modified-Since Header, ob der Wert Last-Modified des Objekts (z. B. Sat, 14 March 2020 19:43:31 GMT) neuer als ein bereitgestellter Wert ist. Wenn das Objekt geändert wurde, wird die Operation fortgesetzt. Wenn das Objekt nicht geändert wurde, gibt das System eine 304 Not Modified zurück.

If-Modified-Since wird normalerweise für zwei unterschiedliche Zwecke verwendet: 1) um effiziente Aktualisierungen einer zwischengespeicherten Darstellung ohne Entitätstag zu ermöglichen und 2) um den Geltungsbereich einer Web-Traversierung auf Ressourcen zu begrenzen, die sich kürzlich geändert haben.

If-Unmodified-Since verwenden

Bei einer Objekt PUT-, HEAD-oder GET-Anforderung prüft der If-Unmodified-Since-Header, ob der Wert Last-Modified des Objekts (z. B. Sat, 14 March 2020 19:43:31 GMT) gleich oder früher als ein angegebener Wert ist. Wenn das Objekt nicht geändert wurde, wird die Operation fortgesetzt. Wenn der Wert für Last-Modified aktueller ist, gibt das System einen 412 Precondition Failed-Fehler in einem PUT und einen 304 Not Modified in GET oder HEAD zurück.

If-Unmodified-Since wird am häufigsten mit Methoden zur Statusänderung (z. B. POST, PUT, DELETE) verwendet, um versehentliche Überschreibungen zu verhindern, wenn mehrere Benutzeragenten parallel für eine Ressource arbeiten, die keine Entitätstags mit ihren Darstellungen liefert (d. h. um das Problem "lost update" zu verhindern). Es kann auch mit sicheren Methoden verwendet werden, um eine Anforderung abzubrechen, wenn die ausgewählte Darstellung nicht mit einer bereits gespeicherten (oder teilweise gespeicherten) aus einer vorherigen Anforderung übereinstimmt.