Mehrere S3-Benutzer in einem Bucket oder pro Benutzer-Buckers

1488
BurnDownTheIgloo

intelligente Leute, noob hier!

Ich plane, auf s3 ein Multi-User-Gerät für die Foto- / Objektspeicherung zu erstellen, und ich hatte vor, s3 zu verwenden. Ich habe das gesamte Frontend geplant, aber ich habe eine Frage zum Eimersystem.

Sollte ich einen Bucket für jeden Benutzer oder 4-5 Buckets haben, auf die die Benutzer verteilt sind, oder sollte ich für jeden Benutzer einen Bucket haben?

Jeder Benutzer wird im Durchschnitt etwa 35 GB speichern, und ich möchte, dass dies in der Lage ist, mit nur drei Benutzern bis zu 300.000.000 in der Zukunft zu laufen (so skalierbar wie möglich).

Welche Methode sollte ich wählen und was hat Dropbox während ihrer S3-Tage gemacht?

1
Als jemand, der ein System aufgebaut hat, das sich so ähnlich anhört, habe ich ein paar Vorschläge: Zuerst benutze Guids, keine Dateinamen. Sie möchten keine zufälligen chinesischen Zeichen in Ihren S3-Dateinamen. Diese sind auf lange Sicht viel einfacher zu handhaben, einfacher, Skripte zusammen zu hacken, und werden Ihnen den Schmerz ersparen. Zweitens ordnen Sie Ihre Hilfslinien in s3: //users-filess3.amazonaws.com/12/345/123-456-789-abc-def. Sie werden irgendwann in die s3-Konsole eintauchen müssen, um das Debugging durchzuführen Wenn sich Millionen Dateien in einem Ordner befinden, ist die Konsole unbrauchbar. KHobbits vor 7 Jahren 0
Ja natürlich. Es ist auch unsicher und eine gewisse Verletzung der Privatsphäre, Dateinamen oder die Dateien selbst in Klartext zu hinterlassen. Vielen Dank für die Eimer-Info! BurnDownTheIgloo vor 7 Jahren 1

1 Antwort auf die Frage

1
Michael - sqlbot

Sie brauchen definitiv keinen Eimer für jeden Benutzer. Vergessen Sie nicht die Tatsache, dass es sehr unwahrscheinlich erscheint, dass der AWS-Support einer Anforderung zustimmt, um das standardmäßige Gesamt-Bucket-Limit Ihres Kontos von 100 auf 300.000.000 zu erhöhen. Die erste Bucket-Erstellung soll nicht aggressiv oder in Echtzeit erfolgen.

Das Hochverfügbarkeits-Engineering von Amazon S3 konzentriert sich auf Vorgänge zum Abrufen, Einfügen, Auflisten und Löschen. Da Bucket-Vorgänge für einen zentralen, globalen Ressourcenbereich arbeiten, ist es nicht angemessen, Buckets im Hochverfügbarkeits-Codepfad Ihrer Anwendung zu erstellen oder zu löschen. Es ist besser, Buckets in einer separaten Initialisierungs- oder Setup-Routine zu erstellen oder zu löschen, die Sie seltener ausführen.

http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html

Entwerfen Sie Ihre Anwendung so, dass es egal ist, ob Sie einen oder mehrere Bucket verwenden. Wie? Speichern Sie für jeden Benutzer die bucket_id, in der die Daten dieses Benutzers gespeichert sind. Beginnen Sie dann mit allen in bucket_id 1 und haben Sie später die Flexibilität, neue Benutzer in neue Buckets zu setzen, wenn dies erforderlich ist ... oder wenn Sie sich entscheiden, einige Benutzer auf andere Buckets zu migrieren ... oder wenn Sie sich entscheiden Lagerung in einem Eimer näher am typischen Standort des Benutzers.

S3 skaliert seine Kapazität automatisch, um die Anforderungen Ihres Datenverkehrs zu erfüllen. Sie können diesen Prozess vereinfachen, indem Sie die Pfade zu Ihren Objekten so gestalten, dass eine nicht sequentielle Zuweisung von Objektschlüsseln in der Nähe der linken Seite des Schlüssels erfolgt.

S3 skaliert seine Kapazität durch Aufteilen der Indexpartitionen. Wenn Sie beispielsweise jedem Objekt einen Pfad geben, der mit dem Datum des Uploads beginnt, wäre dies eine wirklich schlechte Idee, da Ihr Bucket-Index einen Hotspot mit starken Uploads in einem kleinen Teil von der Schlüsselraum.

Siehe http://docs.aws.amazon.com/AmazonS3/latest/dev/request-rate-perf-considerations.html

Aus demselben Grund sollten Sie Ihren Buckets keine lexikalisch sequentiellen Namen in einer Region geben.

Was Dropbox getan hat, ist wahrscheinlich nicht relevant.

Verwandte Probleme