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 die Synchronisation funktioniert

S3 Files sorgt dafür, dass Ihr Dateisystem und der verknüpfte S3-Bucket automatisch synchronisiert werden. Die Daten, die Sie aktiv verwenden, werden in das Dateisystem kopiert, sodass Sie Dateien mit standardmäßigen Linux-Dateioperationen mit geringer Latenz lesen und schreiben können. Für S3 Files muss die S3-Versionierung auf dem verknüpften S3-Bucket aktiviert sein. Wenn Sie Dateien im Dateisystem bearbeiten, kopiert S3 Files Ihre Änderungen als neue Versionen der entsprechenden Objekte zurück in den S3-Bucket, wobei sichergestellt wird, 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 Konfliktfall 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.

Der S3-Bucket ist über das Dateisystem zugänglich

Nachdem Sie ein S3-Dateisystem erstellt haben, können Sie Ihre S3-Buckets auf Rechenressourcen mounten und sofort auf Ihre S3-Bucket-Daten zugreifen. 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 zusammen mit den Daten für Dateien, die kleiner als der Schwellenwert für die Importgröße (Standard 128 KB) sind, aus dem S3-Bucket. Der erste Zugriff auf ein Verzeichnis hat möglicherweise eine höhere Latenz, nachfolgende Lese- und Schreibvorgänge sind jedoch erheblich schneller. Durch den Vorabimport von Metadaten können Sie mit S3 Files Verzeichnisinhalte durchsuchen, Dateigrößen anzeigen und Berechtigungen bei geringer Latenz ü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, die unter dem Schwellenwert für die Importgröße liegen, in das Dateisystem. Diese erste Auflistung kann mehrere Sekunden dauern, aber nachfolgende Befehle wie ls -lastat, oder cat für einzelne Dateien in diesem Verzeichnis werden mit geringer Latenz zurückgegeben.

Bei Dateien, die den Schwellenwert für die Importgröße überschreiten, importiert S3 Files nur Metadaten, während Daten nicht in das Dateisystem kopiert, sondern direkt aus dem S3-Bucket gelesen werden, 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 mehr Daten für Workloads zu importieren, die wiederholt auf dieselben Dateien zugreifen und von Lesevorgängen mit geringer Latenz profitieren. Bei Workloads, bei denen Daten sequentiell gestreamt werden, kann ein niedrigerer Schwellenwert kostengünstiger sein, da der Latenzvorteil beim Import von Daten im Voraus weniger aussagekräftig ist, wenn Daten sequentiell in großen Blöcken gelesen werden und nicht 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 Eigentümer (UID), Gruppe (GID) und Berechtigungsbits, werden als benutzerdefinierte S3-Objektmetadaten in den entsprechenden S3-Objekten gespeichert. Wenn Sie 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 Sie eine Datei im Dateisystem ändern, wartet S3 Files bis zu 60 Sekunden und aggregiert alle in dieser Zeit aufeinanderfolgenden Änderungen an der Datei, bevor sie in Ihren S3-Bucket kopiert werden. Das bedeutet, dass schnelle aufeinanderfolgende Schreibvorgänge in dieselbe Datei in einer einzigen S3-PUT-Anforderung erfasst werden, anstatt für jede einzelne Änderung eine neue Objektversion zu generieren, wodurch Ihre S3-Anforderungs- und Speicherkosten reduziert werden. Wenn Sie die Datei weiter ändern, nachdem S3 Files Ihre Änderungen zurück in den S3-Bucket kopiert hat, werden nachfolgende Änderungen nach Bedarf kopiert.

Wenn eine Anwendung beispielsweise eine Protokolldatei öffnet und innerhalb von 30 Sekunden 50 Mal an sie anhängt, fasst S3 Files alle 50 Anhänge zu einer einzigen S3-PUT-Anforderung zusammen. Wenn die Anwendung nach der ersten Synchronisierung weiter schreibt, kopiert S3 Files die zusätzlichen Änderungen bei einer nachfolgenden Synchronisierung.

Ä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 auf sie zugreifen. Zu diesem Zeitpunkt ruft S3 Files die neueste Version aus dem S3-Bucket ab.

Die Auswirkungen von Umbenennungs- und Verschiebevorgängen verstehen

Amazon S3 verwendet eine flache Speicherstruktur, in der Objekte anhand ihrer Schlüsselnamen identifiziert werden. Mit S3 Files können Sie Ihre Daten zwar in Verzeichnissen organisieren, aber S3 hat kein systemeigenes Konzept von Verzeichnissen. Was in Ihrem Dateisystem als Verzeichnis angezeigt wird, ist ein gemeinsames Präfix, das von den Schlüsseln der Objekte innerhalb des S3-Buckets 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 verwendet. Wenn Sie also ein Verzeichnis mit zig Millionen Dateien umbenennen oder verschieben, erhöhen sich die Kosten für Ihre S3-Anfrage und die Synchronisierungszeit erheblich.

S3 Files gibt einen Fehler zurück, wenn Sie versuchen, ein Dateisystem zu erstellen, das auf ein Präfix mit mehr als 125 Millionen Objekten beschränkt ist. Dieser Fehler weist Sie darauf hin, 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 nach der Umbenennung des Verzeichnisses, aber bevor die Umbenennung vollständig synchronisiert wurde, geschrieben wurden, werden nicht verschoben. Um die Datenreorganisation 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 in seinen neuen Schlüssel innerhalb des S3-Buckets zu kopieren und zu löschen (das projects/alpha/ Präfix durch zu ersetzenprojects/beta/) und das Original zu löschen. Während dieses Vorgangs enthält der S3-Bucket vorübergehend Objekte projects/alpha/ sowohl unter als auchprojects/beta/. Sobald alle Objekte verschoben wurden, projects/beta/ bleibt nur noch übrig.

Ungenutzte Daten sind aus Gründen der Speicheroptimierung aus dem Dateisystem abgelaufen

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 geringer Latenz weiter durchsuchen können.

Wenn eine Datei in Ihrem Dateisystem 30 Tage lang 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 es zurück in das Dateisystem.

Nehmen wir zum Beispiel an, 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, nachfolgende Lesevorgänge sind jedoch schnell.

Der S3-Bucket ist die Quelle der Wahrheit bei Konflikten

Ein Konflikt tritt auf, wenn dieselbe Datei über das Dateisystem geändert wurde und sich auch das entsprechende S3-Objekt geändert hat, bevor S3 Files die Dateisystemänderungen wieder mit dem S3-Bucket synchronisiert hat. Sie können beispielsweise eine Datei über Ihr gemountetes 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 versucht wird, Ihre Dateisystemänderungen wieder mit dem 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. Daher betrachtet S3 Files den S3-Bucket als die Quelle der Wahrheit, 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 Datei, die den Konflikt verursacht, von ihrem aktuellen Speicherort in Ihrem Dateisystem in ein Verzeichnis, das nicht gefunden wurde, 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 and Found und ersetzt sie durch die Version aus dem S3-Bucket.

Das Verzeichnis Lost and Found befindet sich im Stammverzeichnis Ihres Dateisystems unter dem Namen.s3files-lost+found-file-system-id. Wenn S3 Files eine Datei in das Verzeichnis Lost and Found verschiebt, wird dem Dateinamen eine Kennung vorangestellt, um zwischen mehreren Versionen derselben Datei zu unterscheiden, die im Laufe der Zeit möglicherweise verschoben werden. Dateien im Verzeichnis Lost and Found werden nicht in Ihren S3-Bucket kopiert. Sie können Dateien aus diesem Verzeichnis löschen und kopieren, aber Sie können keine Dateien darin verschieben oder umbenennen oder das Verzeichnis selbst löschen. Wenn Sie Ihre Dateisystemänderungen anstelle der neuesten Version im S3-Bucket behalten möchten, kopieren Sie die Datei aus dem Verzeichnis Lost and 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 Lost and Found 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 Standard-Synchronisierungseinstellungen funktionieren bei den 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