Empfehlungen zur Implementierung der S3 REST API
Sie sollten diese Empfehlungen befolgen, wenn Sie die S3 REST-API zur Verwendung mit StorageGRID implementieren.
Empfehlungen für HEADs zu nicht vorhandenen Objekten
Wenn Ihre Anwendung routinemäßig prüft, ob ein Objekt an einem Pfad existiert, an dem Sie das Objekt nicht erwarten, sollten Sie die Option "Verfügbar" verwenden."Konsistenz" . Sie sollten beispielsweise die Konsistenz „Verfügbar“ verwenden, wenn Ihre Anwendung einen HEAD für einen Speicherort vor dem PUT anwendet.
Andernfalls kann es vorkommen, dass Sie, wenn der HEAD-Vorgang das Objekt nicht findet, eine große Anzahl interner Serverfehler vom Typ 500 erhalten, wenn zwei oder mehr Speicherknoten am selben Standort nicht verfügbar sind oder ein Remote-Standort nicht erreichbar ist.
Sie können die "Verfügbare" Konsistenz für jeden Bucket mithilfe der"PUT Bucket-Konsistenz" Anfrage, oder Sie können die Konsistenz im Anfrageheader für eine einzelne API-Operation angeben.
Empfehlungen für Objektschlüssel
Befolgen Sie diese Empfehlungen für Objektschlüsselnamen, basierend auf dem Zeitpunkt der ersten Erstellung des Buckets.
-
Verwenden Sie keine zufälligen Werte als die ersten vier Zeichen der Objektschlüssel. Dies steht im Gegensatz zur früheren AWS-Empfehlung für Schlüsselpräfixe. Verwenden Sie stattdessen nicht zufällige, nicht eindeutige Präfixe, wie etwa
image
. -
Wenn Sie der früheren AWS-Empfehlung folgen, zufällige und eindeutige Zeichen in Schlüsselpräfixen zu verwenden, stellen Sie den Objektschlüsseln einen Verzeichnisnamen voran. Das heißt, verwenden Sie dieses Format:
mybucket/mydir/f8e3-image3132.jpg
Anstelle dieses Formats:
mybucket/f8e3-image3132.jpg
Eine Einschränkung der Objektschlüsselnamen zur Einhaltung der Best Practices für die Leistung ist nicht erforderlich. In den meisten Fällen können Sie für die ersten vier Zeichen von Objektschlüsselnamen zufällige Werte verwenden.
|
Eine Ausnahme hiervon stellt ein S3-Workload dar, der kontinuierlich alle Objekte nach kurzer Zeit entfernt. Um die Auswirkungen auf die Leistung in diesem Anwendungsfall zu minimieren, variieren Sie alle paar tausend Objekte einen führenden Teil des Schlüsselnamens mit etwas wie dem Datum. Nehmen wir beispielsweise an, dass ein S3-Client normalerweise 2.000 Objekte/Sekunde schreibt und die ILM- oder Bucket-Lebenszyklusrichtlinie alle Objekte nach drei Tagen entfernt. Um die Auswirkungen auf die Leistung zu minimieren, können Sie Schlüssel nach einem Muster wie diesem benennen: /mybucket/mydir/yyyymmddhhmmss-random_UUID.jpg
|
Empfehlungen für „Range Reads“
Wenn die"globale Option zum Komprimieren gespeicherter Objekte" aktiviert ist, sollten S3-Clientanwendungen die Durchführung von GetObject-Operationen vermeiden, die einen zurückzugebenden Bytebereich angeben. Diese „Range Read“-Operationen sind ineffizient, da StorageGRID die Objekte effektiv dekomprimieren muss, um auf die angeforderten Bytes zuzugreifen. GetObject-Operationen, die einen kleinen Bytebereich aus einem sehr großen Objekt anfordern, sind besonders ineffizient. Beispielsweise ist es ineffizient, einen 10 MB großen Bereich aus einem komprimierten 50 GB-Objekt zu lesen.
Wenn Bereiche aus komprimierten Objekten gelesen werden, kann es bei Clientanforderungen zu einer Zeitüberschreitung kommen.
|
Wenn Sie Objekte komprimieren müssen und Ihre Clientanwendung Bereichslesevorgänge verwenden muss, erhöhen Sie das Lesezeitlimit für die Anwendung. |