Daten-E/A und Verschlüsselung

Die Objektgröße kann erhebliche Auswirkungen auf die Leistung von IBM Cloud® Object Storage haben. Wählen Sie den richtigen Ansatz für Ihre Workload aus

Mehrteilige Übertragungen

Unter typischen Bedingungen sind mehrteilige Uploads und Downloads eine sehr effiziente Methode, um Übertragungen in viele parallele Transaktionen aufzuteilen. Abhängig von der Objektgröße wird im Allgemeinen eine Teilgröße von 100MB empfohlen. In jedem Fall ist es am effizientesten, die Teilegröße auf ein Vielfaches von 4MiB zu setzen, um die Datenaufnahme in COS und den ausgehenden COS zu optimieren.

Wie bei AWS S3bietet die Verwendung mehrteiliger Übertragungen die folgenden Vorteile:

  • Verbesserter Durchsatz-Sie können Teile parallel hochladen, um den Durchsatz zu verbessern.
  • Schnelle Wiederherstellung nach Netzproblemen-Eine kleinere Teilgröße minimiert die Auswirkungen des Neustarts eines fehlgeschlagenen Uploads aufgrund eines Netzfehlers.
  • Objektuploads anhalten und fortsetzen-Objektteile im Zeitverlauf hochladen. Sobald ein mehrteiliger Upload eingeleitet wird, gibt es keinen Ablauf. Er muss explizit abgeschlossen werden oder der mehrteilige Upload muss abgebrochen werden.
  • Einen Upload beginnen, bevor die endgültige Objektgröße bekannt ist-Ein Objekt kann hochgeladen werden, während es erstellt wird.

Aufgrund der zusätzlichen Komplexität von mehrteiligen Übertragungen wird empfohlen, geeignete S3-Bibliotheken, -Tools oder -SDKs zu verwenden, die Unterstützung für verwaltete mehrteilige Übertragungen bieten:

Es gibt zwar keine dedizierte API für einen mehrteiligen Download, aber es ist möglich, einen Range-Header in einer GET-Anforderung zu verwenden, um nur einen bestimmten Abschnitt eines Objekts zu lesen, und viele bereichsübergreifende Lesevorgänge können parallel ausgeführt werden, wie beim Hochladen von Teilen. Nachdem alle Komponenten heruntergeladen wurden, können sie verknüpft und das vollständige Objekt auf Integrität geprüft werden. Wie bereits erwähnt, wird die Verwendung von SDKs oder anderen Tools empfohlen, um die Komplexität der manuellen Verwaltung dieser Übertragungen zu vermeiden.

Workflows, die eine große Anzahl sehr kleiner Objekte speichern müssen, können besser bedient werden, indem die kleinen Dateien in einer größeren Datenstruktur wie [Parquet]zusammengefasst werden.

Für Objekte mit einer Größe von mehr als 200mb, insbesondere in weniger stabilen Netzen oder über sehr große Entfernungen, bei denen der Paketverlust ein Problem darstellt, kann die Aspera High-Speed Transfer eine hervorragende Leistung liefern. Aspera-Übertragungen können auch verschachtelte Verzeichnisstrukturen effizient innerhalb einer einzelnen Anforderung hochladen.

Löschungen im Stapelbetrieb regulieren

Die S3-API stellt einen Mechanismus für das Löschen von bis zu 1.000 Objekten mit einer einzigen Anforderung zum Löschen im Stapelbetrieb bereit. Es wird empfohlen, diese Anforderungen clientseitig zu drosseln, um die Wahrscheinlichkeit einer Abweichung innerhalb des COS-Systems zu minimieren.  Wenn die Anzahl der abgesetzten Löschungen für das System zu hoch ist, empfängt der Client HTTP 503-Fehler mit einer Fehlernachricht, die auf eine Verlangsamung hinweist.

Auswirkungen auf die Konsistenz

IBM Cloud Object Storage System garantiert sofortige Konsistenz für alle Objektoperationen, einschließlich Objektschreiboperationen, Überschreibungen, Löschoperationen, mehrteiligen Operationen und ACL-Änderungen. Die Bucketerstellung ist ebenfalls sofort konsistent.  Die Bucketmetadaten und die Konfiguration sind schließlich konsistent, wie dies bei anderen Objektspeichersystemen der Fall ist. Dies bedeutet, dass Änderungen in einem hoch verteilten System für einen kurzen Zeitraum möglicherweise nicht synchronisiert werden. Dies ist auf das Caching von Metadaten zurückzuführen, das erhebliche Leistungsvorteile bietet und auch vor Denial-of-Service-Attacken schützt.

Einige Anwendungen überschreiben dasselbe Objekt oder löschen und schreiben dasselbe Objekt wiederholt über einen kurzen Zeitraum. Dies kann zu Konkurrenzsituationen in den Indizes im COS-System führen und sollte vermieden werden.  In dem seltenen Fall, dass das Überschreiben von Daten mit demselben Objektschlüssel (Name) mit sehr hoher Häufigkeit und über längere Zeiträume hinweg ein kritischer Aspekt eines Anwendungsdesigns ist, kann eine andere Speicherplattform (Datei, Block, noSQLusw.) eine bessere Wahl sein.

Existenzprüfungen

Anwendungen können vor dem Schreiben prüfen, ob ein Objekt vorhanden ist oder geändert wurde.  Dies führt häufig zu einer ineffizienten Anwendungslogik, die eine HEAD-Anforderung gefolgt von einer PUT-oder GET-Anforderung sendet.  Dieses Anti-Muster führt zu verschwendeten Netz-und Serverressourcen und sollte nicht empfohlen werden.

Verwenden Sie anstelle einer HEAD-Anforderung als Existenzprüfung in einer Funktion einen bedingten Anforderungsheader.  Diese Standard-HTTP-Header vergleichen MD5-Hashes oder -Zeitmarken, um zu bestimmen, ob die Datenoperation fortgesetzt werden soll.  Weitere Informationen finden Sie unter Bedingte Anforderungen.

Bedingte Anforderungen verwenden

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. Hierfür werden die folgenden vorbedingten HTTP-Header verwendet: 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 Objektanforderung PUT, HEAD oder GET prüft der Header If-Match, 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 Objektanforderung PUT, HEAD oder GET prüft der Header If-None-Match, 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 auf einem PUT und einen 304 Not Modified unter 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.

Verwenden von If-Modified-Since

Bei einer Objekt HEAD-oder GET-Anforderung prüft der Header If-Modified-Since, 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: um effiziente Aktualisierungen einer zwischengespeicherten Darstellung ohne Etag zu ermöglichen und den Geltungsbereich einer Web-Traversierung auf Ressourcen zu begrenzen, die kürzlich geändert wurden.

Verwenden von If-Unmodified-Since

Bei einer Objektanforderung PUT, HEAD oder GET prüft der Header If-Unmodified-Since, 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 Last-Modified aktueller ist, gibt das System einen 412 Precondition Failed-Fehler auf einem PUT und einen 304 Not Modified unter 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.

Wiederholungsstrategie

Während die meisten Bibliotheken und SDKs Wiederholungslogik automatisch verarbeiten, muss beim Schreiben von Software, die die API direkt verwendet, Vorsicht geboten werden, um transiente Fehler ordnungsgemäß zu behandeln. Am wichtigsten ist, dass es wichtig ist, eine geeignete Wiederholungslogik bereitzustellen, die eine exponentielle Aussetzfunktion implementiert, wenn 503 Fehler empfangen werden.

Cypher-Optimierung

IBM COS unterstützt eine Vielzahl von Verschlüsselungseinstellungen für die Verschlüsselung von Daten bei der Übertragung. Nicht alle Verschlüsselungseinstellungen führen zu derselben Leistung und die Verwendung von TLS führt im Allgemeinen zu kleinen Leistungseinbußen. Die folgenden Verschlüsselungseinstellungen werden empfohlen (in absteigender Reihenfolge der Priorität):

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA