S3 - Was genau ist ein Präfix? Und welche Ratelimits gelten?

Ich habe mich gefragt, ob jemand genau weiß, was ein S3-Präfix ist und wie es mit den von Amazon veröffentlichten S3-Ratenlimits interagiert :

Amazon S3 skaliert automatisch auf hohe Anforderungsraten. Beispielsweise kann Ihre Anwendung mindestens 3.500 PUT / POST / DELETE- und 5.500 GET-Anforderungen pro Sekunde und Präfix in einem Bucket erreichen. Die Anzahl der Präfixe in einem Bucket ist unbegrenzt.

Während das wirklich klar ist, bin ich mir nicht ganz sicher, was ein Präfix ist?

Benötigt ein Präfix ein Trennzeichen?

Wenn wir einen Bucket haben, in dem wir alle Dateien auf der "Root" -Ebene speichern (vollständig flach, ohne Präfix / Trennzeichen), zählt dies als einzelnes "Präfix" und unterliegt es den oben angegebenen Ratenbeschränkungen?

Die Art und Weise, wie ich die Dokumentation von amazon interpretiere , legt mir nahe, dass dies der Fall ist und dass die flache Struktur als ein einziges "Präfix" betrachtet wird. (dh es würde den oben genannten veröffentlichten Tarifgrenzen unterliegen)

Angenommen, Ihr Bucket (vom Administrator erstellt) enthält vier Objekte mit den folgenden Objektschlüsseln:

Entwicklung / Projekte1.xls

Finanzen / Statement1.pdf

Privat / taxdocument.pdf

s3-dg.pdf

Der Schlüssel s3-dg.pdf hat kein Präfix, daher wird sein Objekt direkt auf der Stammebene des Buckets angezeigt. Wenn Sie den Ordner Development / öffnen, wird das Projects.xlsx-Objekt darin angezeigt.

Würde im obigen Beispiel s3-dg.pdf einem anderen Ratenlimit (5500 GET-Anforderungen / Sekunde) unterliegen als jedes der anderen Präfixe (Entwicklung / Finanzen / Privat)?

Was verwirrender ist, ist, dass ich ein paar Blogs über Amazon gelesen habe, in denen die ersten N Bytes als Partitionsschlüssel verwendet wurden und die Verwendung von Präfixen mit hoher Kardinalität empfohlen wurden. Ich bin mir nur nicht sicher, wie dies mit einem Bucket mit einer "flachen Dateistruktur" interagiert. .

Sie haben Recht, die Ankündigung scheint sich zu widersprechen. Es ist einfach nicht richtig geschrieben, aber die Informationen sind korrekt. Zusamenfassend:

1. Jedes Präfix kann bis zu 3.500 / 5.500 Anforderungen pro Sekunde erfüllen. Für viele Zwecke wird daher davon ausgegangen, dass Sie nicht mehrere Präfixe verwenden müssen.
2. Präfixe gelten als der gesamte Pfad (bis zum letzten '/') der Position eines Objekts und werden nicht mehr nur von den ersten 6-8 Zeichen gehasht. Daher würde es ausreichen, die Daten einfach auf zwei beliebige "Ordner" aufzuteilen, um x2 maximale Anforderungen pro Sekunde zu erreichen. (wenn Anfragen gleichmäßig zwischen den beiden aufgeteilt werden)

Als Referenz finden Sie hier eine Antwort des AWS-Supports auf meine Anfrage zur Klärung:

Hallo Oren,

Vielen Dank, dass Sie sich an den AWS-Support gewandt haben.

Ich verstehe, dass Sie den AWS-Beitrag über die Leistungssteigerung der S3-Anforderungsrate gelesen haben und zusätzliche Fragen zu dieser Ankündigung haben.

Vor diesem Upgrade unterstützte S3 100 PUT / LIST / DELETE-Anforderungen pro Sekunde und 300 GET-Anforderungen pro Sekunde. Um eine höhere Leistung zu erzielen, musste ein zufälliges Hash- / Präfixschema implementiert werden. Seit dem letzten Jahr sind die Grenzwerte für die Anforderungsrate auf 3.500 PUT / POST / DELETE- und 5.500 GET-Anforderungen pro Sekunde gestiegen. Diese Erhöhung reicht häufig aus, damit Anwendungen 503 SlowDown-Fehler verringern können, ohne Präfixe zufällig auswählen zu müssen.

Wenn die neuen Grenzwerte jedoch nicht ausreichen, müssen Präfixe verwendet werden. Ein Präfix hat keine feste Anzahl von Zeichen. Es ist eine beliebige Zeichenfolge zwischen einem Bucket-Namen und einem Objektnamen, zum Beispiel:

• Bucket / Ordner1 / Sub1 / Datei
• Bucket / Ordner1 / Sub2 / Datei
• Bucket / 1 / Datei
• Bucket / 2 / Datei

Präfixe des Objekts ‚Datei‘ wäre: /folder1/sub1/, /folder1/sub2/, /1/, /2/. In diesem Beispiel können Sie 22.000 Anforderungen pro Sekunde erzielen, wenn Sie die Lesevorgänge gleichmäßig auf alle vier Präfixe verteilen.

Dies scheint in einer Amazon-Release-Mitteilung unklar zu sein

https://aws.amazon.com/about-aws/whats-new/2018/07/amazon-s3-announces-increased-request-rate-performance/

Die Leistung wird pro Präfix skaliert, sodass Sie so viele Präfixe verwenden können, wie Sie parallel benötigen, um den erforderlichen Durchsatz zu erzielen. Die Anzahl der Präfixe ist unbegrenzt.

Durch diese Leistungssteigerung der S3-Anforderungsrate werden alle vorherigen Anleitungen zum Randomisieren von Objektpräfixen entfernt, um eine schnellere Leistung zu erzielen. Das bedeutet, dass Sie jetzt logische oder sequentielle Benennungsmuster bei der S3-Objektbenennung verwenden können, ohne dass dies Auswirkungen auf die Leistung hat. Diese Verbesserung ist jetzt in allen AWS-Regionen verfügbar. Weitere Informationen finden Sie im Amazon S3 Developer Guide.

Damit AWS Milliarden von Anforderungen pro Sekunde verarbeiten kann, müssen die Daten aufgespalten werden, um den Durchsatz zu optimieren. Dazu teilen sie die Daten basierend auf den ersten 6 bis 8 Zeichen des Objektschlüssels in Partitionen auf. Denken Sie daran, dass S3 kein hierarchisches Dateisystem ist, sondern nur ein Schlüsselwertspeicher, obwohl der Schlüssel häufig als Dateipfad zum Organisieren von Daten verwendet wird, Präfix + Dateiname.

Dies ist kein Problem, wenn Sie weniger als 100 Anfragen pro Sekunde erwarten. Wenn Sie jedoch ernsthafte Anforderungen haben, müssen Sie über die Benennung nachdenken.

Für einen maximalen parallelen Durchsatz sollten Sie berücksichtigen, wie Ihre Daten verwendet werden, und die unterschiedlichsten Zeichen am Anfang Ihres Schlüssels verwenden oder sogar 8 zufällige Zeichen für die ersten 8 Zeichen des Schlüssels generieren.

Angenommen, die ersten 6 Zeichen definieren die Partition:

files/user/bobwäre schlecht, da sich alle Objekte auf einer Partition befinden würden files/.

2018-09-21/files/bobwäre fast genauso schlimm, wenn nur heutige Daten von der Partition gelesen würden 2018-0. Aber etwas besser, wenn die Objekte aus den vergangenen Jahren gelesen werden.

bob/users/fileswäre ziemlich gut, wenn wahrscheinlich verschiedene Benutzer die Daten gleichzeitig von der Partition aus verwenden würden bob/us. Aber nicht so gut, wenn Bob bei weitem der meistbeschäftigte Benutzer ist.

3B6EA902/files/users/bobwäre am besten für die Leistung, aber schwieriger zu referenzieren, wo der erste Teil eine zufällige Zeichenfolge ist, wäre dies ziemlich gleichmäßig verteilt.

Abhängig von Ihren Daten müssen Sie an einen bestimmten Zeitpunkt denken, wer was liest, und sicherstellen, dass die Schlüssel mit genügend Variationen beginnen, um eine angemessene Partitionierung zu ermöglichen.

Nehmen wir für Ihr Beispiel an, dass die Partition aus den ersten 6 Zeichen des Schlüssels stammt:

für den Schlüssel wäre Development/Projects1.xlsder PartitionsschlüsselDevelo

für den Schlüssel wäre Finance/statement1.pdfder PartitionsschlüsselFinanc

für den Schlüssel wäre Private/taxdocument.pdfder PartitionsschlüsselPrivat

für den Schlüssel wäre s3-dg.pdfder Partitionsschlüssels3-dg.

Die positive Antwort darauf war für mich etwas irreführend. Wenn dies die Pfade sind

Bucket / Ordner1 / Sub1 / Datei
Bucket / Ordner1 / Sub2 / Datei
Bucket / 1 / Datei
Bucket / 2 / Datei

Ihr Präfix für die Datei wäre tatsächlich
Ordner1 / Sub1 /
Ordner1 / Sub2 /
1 / Datei
2 / Datei

https://docs.aws.amazon.com/AmazonS3/latest/dev/ListingKeysHierarchy.html Bitte siehe Dokumente. Ich hatte Probleme mit dem führenden '/', als ich versuchte, Schlüssel mit dem Luftstrom-s3hook aufzulisten.

S3-Präfixe wurden früher durch die ersten 6-8 Zeichen bestimmt.

Dies hat sich Mitte 2018 geändert - siehe Ankündigung https://aws.amazon.com/about-aws/whats-new/2018/07/amazon-s3-announces-increased-request-rate-performance/

Aber das ist die halbe Wahrheit . Tatsächlich sind Präfixe (in alter Definition) immer noch wichtig.

S3 ist kein traditioneller „Speicher“ - jedes Verzeichnis / Dateiname ist ein separates Objekt in einem Schlüssel- / Wertobjektspeicher. Außerdem müssen die Daten partitioniert / aufgeteilt werden, um sie auf Billiarden von Objekten zu skalieren. Also ja, dieses neue Sharding ist ein bisschen "automatisch", aber nicht wirklich, wenn Sie einen neuen Prozess erstellt haben, der mit verrückter Parallelität zu verschiedenen Unterverzeichnissen darauf schreibt. Bevor der S3 aus dem neuen Zugriffsmuster lernt, kann es zu einer S3-Drosselung kommen, bevor die Daten entsprechend neu gehostet / neu partitioniert werden.

Das Erlernen neuer Zugriffsmuster braucht Zeit. Die Neupartitionierung der Daten nimmt Zeit in Anspruch.

Mitte 2018 haben sich die Dinge verbessert (~ 10-facher Durchsatz für einen neuen Bucket ohne Statistik), aber es ist immer noch nicht das, was es sein könnte, wenn die Daten ordnungsgemäß partitioniert werden. Um fair zu sein, wird dies möglicherweise nicht auf Sie angewendet, wenn Sie nicht über eine Menge Daten verfügen oder das Muster für den Zugriff auf Daten nicht sehr parallel ist (z. B. Ausführen eines Hadoop / Spark-Clusters auf vielen Tbs Daten in S3 mit Hunderten + von Aufgaben, die parallel auf denselben Bucket zugreifen).

TLDR :

"Alte Präfixe" spielen immer noch eine Rolle. Schreiben Sie Daten in das Stammverzeichnis Ihres Buckets, und das Verzeichnis der ersten Ebene bestimmt dort das "Präfix" (machen Sie es zum Beispiel zufällig).

"Neue Präfixe" funktionieren, aber zunächst nicht. Das Laden dauert einige Zeit.

PS. Ein anderer Ansatz: Sie können sich an Ihren AWS TAM wenden (falls vorhanden) und ihn bitten, einen neuen S3-Bucket vorab zu partitionieren, wenn Sie erwarten, dass eine Menge Daten ihn bald überfluten werden.

Wenn Sie S3 mit Athena, EMR / Hive oder Redshift Spectrum abfragen, kann das Erhöhen der Anzahl der Präfixe das Hinzufügen weiterer Partitionen bedeuten (da die Partitions-ID Teil des Präfixes ist). Wenn Sie datetime als einen Ihrer Partitionsschlüssel verwenden, wächst die Anzahl der Partitionen (und Präfixe) automatisch, wenn im Laufe der Zeit neue Daten hinzugefügt werden, und die Gesamtzahl der maximalen S3-GETs pro Sekunde steigt ebenfalls.