Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verstehen, wie Synchronisation funktioniert

Mit S3 Files werden Ihr Dateisystem und der verknüpfte S3-Bucket automatisch synchronisiert. Die Daten, die Sie aktiv verwenden, werden in das Dateisystem kopiert, sodass Sie Dateien mit Standard-Linux-Dateioperationen bei niedriger Latenz lesen und schreiben können. S3 Files erfordert, dass die S3-Versionsverwaltung auf dem verknüpften S3-Bucket aktiviert ist. Wenn Sie Dateien im Dateisystem bearbeiten, kopiert S3 Files Ihre Änderungen als neue Versionen der entsprechenden Objekte zurück in den S3-Bucket. Dabei wird sichergestellt, dass die alten Versionen erhalten bleiben. Wenn andere Anwendungen Objekte in Ihrem S3-Bucket hinzufügen, ändern oder löschen, spiegelt S3 Files diese Änderungen automatisch in Ihrem Dateisystem wider. Wenn ein Konflikt aufgrund gleichzeitiger Änderungen an denselben Daten sowohl im Dateisystem als auch im S3-Bucket auftritt, behandelt S3 Files den S3-Bucket im Falle von Konflikten als Informationsquelle.

Um die Speicherkosten zu optimieren, entfernt S3 Files Daten, die Sie in letzter Zeit nicht verwendet haben, aus dem Dateisystem. Ihre Daten bleiben dauerhaft im verknüpften S3-Bucket gespeichert und werden beim nächsten Zugriff wieder in das Dateisystem abgerufen.

Auf den S3-Bucket kann über das Dateisystem zugegriffen werden

Nachdem Sie ein S3-Dateisystem erstellt haben, können Sie Ihre S3-Buckets auf Rechenressourcen bereitstellen und sofort mit dem Zugriff auf Ihre S3-Bucket-Daten beginnen. Wenn Sie zum ersten Mal auf ein Verzeichnis zugreifen, indem Sie dessen Inhalt auflisten oder eine darin enthaltene Datei öffnen, importiert S3 Files standardmäßig die Metadaten für alle Dateien in diesem Verzeichnis sowie die Daten für Dateien, die kleiner als der Schwellenwert für die Importgröße (standardmäßig 128 KiB) sind, aus dem S3-Bucket. Der erste Zugriff auf ein Verzeichnis hat möglicherweise eine höhere Latenz, aber nachfolgende Lese- und Schreibvorgänge sind deutlich schneller. Durch den Import von Metadaten im Voraus ermöglicht Ihnen S3 Files, Verzeichnisinhalte zu durchsuchen, Dateigrößen anzuzeigen und Berechtigungen mit geringer Latenz zu überprüfen.

Nehmen wir zum Beispiel an, Ihr S3-Bucket enthält ein Präfix data/images/ mit 1.000 Objekten. Bei der ersten Ausführung ls /mnt/s3files/data/images/ importiert S3 Files Metadaten für alle 1.000 Dateien und kopiert asynchron Daten für Dateien unter dem Schwellenwert für die Importgröße in das Dateisystem. Diese erste Auflistung kann einige Sekunden dauern, aber nachfolgende Befehle wiels -la,stat, oder cat für einzelne Dateien in diesem Verzeichnis kehren mit geringer Latenz zurück.

Bei Dateien, die den Schwellenwert für die Importgröße überschreiten, importiert S3 Files nur Metadaten. Daten werden nicht in das Dateisystem kopiert, sondern direkt aus dem S3-Bucket gelesen, wenn Sie darauf zugreifen. Sie können diesen Schwellenwert anpassen, um ihn besser an Ihre Arbeitslast anzupassen. Sie können ihn beispielsweise erhöhen, um im Voraus mehr Daten für Workloads zu importieren, die wiederholt auf dieselben Dateien zugreifen und von Lesevorgängen mit niedriger Latenz profitieren. Bei Workloads, die Daten sequentiell streamen, kann ein niedrigerer Schwellenwert kostengünstiger sein, da der Latenzvorteil des Imports von Daten im Voraus weniger bedeutsam ist, wenn Daten sequentiell in großen Blöcken gelesen werden, anstatt in kleinen, zufälligen Lesevorgängen. Weitere Informationen finden Sie unter Synchronisation für S3-Dateien anpassen.

Änderungen in Ihrem Dateisystem werden automatisch in Ihrem S3-Bucket widergespiegelt

Wenn Sie Dateien im Dateisystem erstellen, ändern oder löschen, kopiert S3 Files diese Änderungen automatisch in Ihren S3-Bucket. Neue Dateien werden zu neuen S3-Objekten, Änderungen an vorhandenen Dateien werden zu neuen Objektversionen und gelöschte Dateien werden zu S3-Löschmarkierungen.

POSIX-Berechtigungen, die Sie über das Dateisystem für Dateien und Verzeichnisse festlegen, wie Besitzer (UID), Gruppe (GID) und Berechtigungsbits, werden als benutzerdefinierte S3-Objektmetadaten in den entsprechenden S3-Objekten gespeichert. Wenn Sie die Berechtigungen mithilfe vonchmod, oder chgrp ändernchown, exportiert S3 Files diese Änderungen zusammen mit allen Datenänderungen in Ihren S3-Bucket. Wenn S3 Files Objekte aus Ihrem S3-Bucket importiert, liest es diese Metadaten und wendet die entsprechenden POSIX-Berechtigungen auf das Dateisystem an. Objekten, die keine POSIX-Berechtigungsmetadaten haben, werden Standardberechtigungen zugewiesen.

Wenn eine Datei im Dateisystem geändert wird, wartet S3 Files eine Zeit der Schreibinaktivität (60 Sekunden) ab, bevor diese Änderungen zurück in Ihren S3-Bucket exportiert werden. Schnelle aufeinanderfolgende Schreibvorgänge in dieselbe Datei werden in einer einzigen S3-PUT-Anforderung erfasst, anstatt für jede einzelne Änderung mehrere Objektversionen zu generieren. Dies reduziert sowohl Ihre S3-Anforderungskosten als auch Ihre Speicherkosten. Sie können dieses 60-Sekunden-Inaktivitätsfenster als Export-Trigger verwenden. Wenn Ihre Anwendung beispielsweise insgesamt 5 Minuten lang alle 30 Sekunden Daten an eine Datei anhängt, startet S3 Files den Exportvorgang in Minute 6. Wenn Sie weitere Änderungen vornehmen, wird der Vorgang nach jeweils 60 Sekunden ohne Schreibaktivität wiederholt.

Änderungen in Ihrem S3-Bucket werden automatisch in Ihrem Dateisystem angezeigt

S3 Files überwacht Änderungen in Ihrem S3-Bucket mithilfe von S3-Ereignisbenachrichtigungen. Wenn eine andere Anwendung, die mit der S3-API arbeitet, Objekte in Ihrem S3-Bucket hinzufügt, ändert oder löscht, spiegelt S3 Files automatisch diese Änderungen im Dateisystem für Dateien wider, deren Daten derzeit im Hochleistungsspeicher des Dateisystems gespeichert sind. Dateien, deren Daten aus dem Dateisystem abgelaufen sind, werden erst aktualisiert, wenn Sie das nächste Mal darauf zugreifen. Zu diesem Zeitpunkt ruft S3 Files die neueste Version aus dem S3-Bucket ab.

Die Auswirkungen von Umbenennungs- und Verschiebungsvorgängen verstehen

Amazon S3 verwendet eine flache Speicherstruktur, in der Objekte anhand ihrer Schlüsselnamen identifiziert werden. Während Sie mit S3 Files Ihre Daten in Verzeichnissen organisieren können, gibt es in S3 kein systemeigenes Konzept von Verzeichnissen. Was in Ihrem Dateisystem als Verzeichnis erscheint, ist ein gemeinsames Präfix, das von den Schlüsseln der Objekte im S3-Bucket gemeinsam genutzt wird. Darüber hinaus sind S3-Objekte unveränderlich und unterstützen keine atomaren Umbenennungen. Wenn Sie eine Datei umbenennen oder verschieben, muss S3 Files daher die Daten mit dem aktualisierten Schlüssel in ein neues Objekt schreiben und das Original löschen. Wenn Sie ein Verzeichnis umbenennen oder verschieben, muss S3 Files diesen Vorgang für jedes Objekt wiederholen, das dieses Präfix gemeinsam hat. Wenn Sie also ein Verzeichnis umbenennen oder verschieben, das zig Millionen von Dateien enthält, erhöhen sich Ihre S3-Anforderungskosten und die Synchronisationszeit erheblich.

S3 Files gibt einen Fehler zurück, wenn Sie versuchen, ein Dateisystem zu erstellen, das auf ein Präfix mit einer großen Anzahl von Objekten beschränkt ist, sodass eine Umbenennung bis zu 4 Stunden dauern kann (ungefähr bis zu 12 Millionen Objekte). Dieser Fehler warnt Sie davor, dass umfangreiche rekursive Umbenennungs- oder Verschiebevorgänge die Leistung des Dateisystems beeinträchtigen können, da für jede Datei separate Schreib- und Löschanforderungen an Ihren S3-Bucket erforderlich sind. Wenn Sie dennoch ein Dateisystem erstellen möchten, das auf dieses Präfix beschränkt ist, können Sie den Parameter hinzufügen. --AcceptBucketWarning

Da S3 Files Objekte im S3-Bucket einzeln umbenennt, sind beide Verzeichnisse im S3-Bucket sichtbar, bis die Umbenennung vollständig abgeschlossen ist. Objekte, die geschrieben wurden, nachdem das Verzeichnis umbenannt wurde, aber bevor diese Umbenennung vollständig synchronisiert wurde, werden nicht verschoben. Um die Reorganisation der Daten zu vereinfachen, empfehlen wir, beim Umbenennen eines passenden Verzeichnisses keine neuen Objekte über den S3-Bucket zu erstellen.

Wenn Sie beispielsweise ausführenmv /mnt/s3files/projects/alpha /mnt/s3files/projects/beta, wird die Umbenennung im Dateisystem sofort abgeschlossen. Im S3-Bucket beginnt S3 Files, jedes Objekt zu kopieren und zu löschen, und zwar auf seinen neuen Schlüssel im S3-Bucket (wobei das projects/alpha/ Präfix durch ersetzt wirdprojects/beta/) und das Original wird gelöscht. Während dieses Vorgangs enthält der S3-Bucket vorübergehend Objekte unter projects/alpha/ sowohl als auchprojects/beta/. Sobald alle Objekte verschoben wurden, projects/beta/ bleibt nur noch etwas übrig.

Ungenutzte Daten werden aus dem Dateisystem gelöscht, um die Speicherung zu optimieren

S3 Files optimiert die Speicherkosten, indem Dateidaten, die in letzter Zeit nicht gelesen wurden, automatisch aus dem Dateisystem entfernt werden. Ihre Daten bleiben sicher in Ihrem S3-Bucket gespeichert. S3 Files entfernt nur die Kopie aus dem Dateisystem. Dateimetadaten wie Namen, Größen und Berechtigungen werden niemals aus dem Dateisystem entfernt, sodass Sie Ihr Dateisystem mit niedriger Latenz weiter durchsuchen können.

Wenn eine Datei in Ihrem Dateisystem seit 30 Tagen nicht gelesen wurde (konfigurierbar) und ihre Änderungen bereits mit dem S3-Bucket synchronisiert wurden, entfernt S3 Files die Dateidaten aus dem Dateisystem. Wenn Sie diese Datei das nächste Mal lesen, ruft S3 Files die neueste Version des entsprechenden Objekts aus dem S3-Bucket ab und kopiert sie zurück in das Dateisystem.

Angenommen, Sie verarbeiten einen Datensatz /mnt/s3files/data/batch-jan.parquet im Januar und greifen nicht erneut darauf zu. Nach 30 Tagen entfernt S3 Files die Dateidaten aus dem Dateisystem. Die Datei wird immer noch mit der richtigen Größe und den richtigen Berechtigungen in den Verzeichnislisten angezeigt, aber die Daten befinden sich nicht mehr im Dateisystem. Wenn Sie die Datei im April erneut lesen, ruft S3 Files sie aus dem S3-Bucket ab und kopiert sie zurück in das Dateisystem. Der erste Lesevorgang hat möglicherweise eine höhere Latenz, aber nachfolgende Lesevorgänge sind schnell.

Der S3-Bucket ist die Quelle der Wahrheit im Falle von Konflikten

Ein Konflikt tritt auf, wenn dieselbe Datei über das Dateisystem geändert wurde und das entsprechende S3-Objekt ebenfalls geändert wurde, bevor S3 Files die Dateisystemänderungen wieder mit dem S3-Bucket synchronisiert hat. Sie können beispielsweise eine Datei über Ihr bereitgestelltes Dateisystem bearbeiten, während eine andere Anwendung eine neue Version des entsprechenden Objekts direkt im verknüpften S3-Bucket hochlädt oder löscht.

S3 Files erkennt Konflikte, wenn es versucht, Ihre Dateisystemänderungen zurück in den S3-Bucket zu synchronisieren, oder wenn es eine S3-Ereignisbenachrichtigung erhält, die darauf hinweist, dass sich das Objekt geändert hat. Ihr S3-Bucket dient als langfristiger Speicher für Ihre Daten, sodass S3 Files den S3-Bucket als die Quelle der Wahrheit betrachtet, wenn ein Konflikt auftritt. Dies sorgt für vorhersehbare Konsistenz und stellt sicher, dass die Version in Ihrem S3-Bucket immer Vorrang hat. Im Falle eines Konflikts verschiebt S3 Files die widersprüchliche Datei von ihrem aktuellen Speicherort in Ihrem Dateisystem in ein Verzeichnis, in dem Sie verloren gegangen sind, und importiert die neueste Version aus dem verknüpften S3-Bucket in das Dateisystem.

Nehmen wir zum Beispiel an, Sie bearbeiten die Datei /mnt/s3files/report.csv über das Dateisystem. Bevor S3 Files Ihre Änderungen wieder mit dem S3-Bucket synchronisiert, lädt eine andere Anwendung eine neue Version von report.csv direkt in den S3-Bucket hoch. Wenn S3 Files den Konflikt erkennt, verschiebt es Ihre Version von report.csv in das Verzeichnis Lost & Found und ersetzt sie durch die Version aus dem S3-Bucket.

Das Verzeichnis „Verloren und gefunden“ befindet sich im Stammverzeichnis Ihres Dateisystems unter dem Namen.s3files-lost+found-file-system-id. Wenn Sie Ihr Dateisystem über einen Access Point mounten, der ein Stammverzeichnis angibt, ist das Verzeichnis Lost & Found von diesem Mount aus nicht sichtbar, da es sich über dem Stammverzeichnis des Access Points befindet. Um auf das Verzeichnis „Verloren und gefunden“ zuzugreifen, mounten Sie das Dateisystem ohne Access Point oder verwenden Sie einen Access Point ohne Root-Verzeichnisbeschränkung, sodass Sie über den Access Point auf den gesamten Umfang des Dateisystems zugreifen können.

Wenn S3 Files eine Datei in das Verzeichnis „Verloren und gefunden“ verschiebt, wird dem Dateinamen eine Kennung vorangestellt, um mehrere Versionen derselben Datei zu unterscheiden, die im Laufe der Zeit verschoben werden könnten. Dateien im Verzeichnis „Verloren und gefunden“ werden nicht in Ihren S3-Bucket kopiert. Sie können Dateien löschen und Dateien aus diesem Verzeichnis kopieren, aber Sie können darin enthaltene Dateien nicht verschieben oder umbenennen oder das Verzeichnis selbst löschen. Wenn Sie Ihre Dateisystemänderungen und nicht die neueste Version im S3-Bucket behalten möchten, kopieren Sie die Datei aus dem Verzeichnis Lost & Found zurück in ihren ursprünglichen Pfad. Sie können den ursprünglichen Pfad der Datei aus den erweiterten Attributen der Datei im Verzeichnis „Verloren und gefunden“ abrufen. S3 Files kopiert es dann als neue Version des Objekts in Ihren S3-Bucket. Weitere Informationen finden Sie unter Problembehandlung bei S3-Dateien.

Die Standardsynchronisierungseinstellungen funktionieren für die meisten Workloads für den dateibasierten Zugriff auf S3-Daten mit niedriger Latenz. Weitere Informationen zur Konfiguration dieser Parameter finden Sie unter. Synchronisation für S3-Dateien anpassen