Pour un système de fichiers piloté par une combinaison de stockage d'objets et de base de données, la mise en cache est un lien important pour une interaction efficace entre les clients locaux et les services distants. Les données de lecture et d'écriture peuvent être chargées dans le cache à l'avance ou de manière asynchrone, puis le client interagit avec le service distant en arrière-plan pour effectuer un téléchargement asynchrone ou une prélecture des données. Par rapport à l'interaction directe avec des services distants, l'utilisation de la technologie de mise en cache peut réduire considérablement la latence des opérations de stockage et améliorer le débit des données.
la cohérence des données
JuiceFS fournit une garantie de cohérence "close-to-open", c'est-à-dire que lorsque deux clients ou plus lisent et écrivent le même fichier en même temps, les modifications du client A peuvent ne pas être immédiatement visibles pour le client B. Cependant, une fois le fichier écrit sur le client A et fermé, la réouverture ultérieure du fichier sur n'importe quel client garantit l'accès aux dernières données écrites, que ce soit sur le même nœud ou non.
"Fermer et rouvrir" est la garantie de cohérence minimale fournie par JuiceFS. Dans certains cas, il peut ne pas être nécessaire de rouvrir le fichier pour accéder aux dernières données écrites. Par exemple, plusieurs applications utilisent le même client JuiceFS pour accéder au même fichier (les modifications de fichier sont immédiatement visibles) ou pour afficher les dernières données via des tail -fcommandes .
cache de métadonnées
JuiceFS prend en charge la mise en cache des métadonnées dans le noyau et la mémoire client (c'est-à-dire le processus JuiceFS) pour améliorer les performances d'accès aux métadonnées.
Cache de métadonnées du noyau
Trois types de métadonnées peuvent être mises en cache dans le noyau : attribut , entrée et répertoire. Le temps de mise en cache peut être contrôlé par les paramètres de montage suivants :
--attr-cache value 属性缓存时长，单位秒 (默认值: 1)
--entry-cache value 文件项缓存时长，单位秒 (默认值: 1)
--dir-entry-cache value 目录项缓存时长，单位秒 (默认值: 1)
JuiceFS met en cache les attributs, les éléments de fichier et les éléments de répertoire dans le noyau par défaut pendant 1 seconde pour améliorer les performances de la recherche et de getattr. Lorsque les clients de plusieurs nœuds utilisent le même système de fichiers en même temps, les métadonnées mises en cache dans le noyau ne peuvent être invalidées qu'au fil du temps. C'est-à-dire que, dans des cas extrêmes, le nœud A peut modifier les métadonnées d'un fichier (par exemple chown), et l'accès via le nœud B ne peut pas voir la mise à jour immédiatement. Bien sûr, après l'expiration du cache, tous les nœuds verront éventuellement les modifications apportées par A.
Cache de métadonnées en mémoire côté client
Remarque : Cette fonctionnalité nécessite JuiceFS version 0.15.0 et supérieure.
Lorsqu'un client open()JuiceFS ouvre un fichier, ses attributs de fichier sont automatiquement mis en cache dans la mémoire client. Si l' --open-cacheoption valeur supérieure à 0, les opérationsgetattr() suivantes et renverront immédiatement le résultat du cache en mémoire, tant que le cache n'a pas expiré.open()
Lors de l'exécution read()d'une opération , à savoir la lecture d'un fichier, les informations de bloc et de tranche du fichier seront automatiquement mises en cache dans la mémoire client. Pendant la période de validité du cache, la lecture à nouveau du morceau renverra immédiatement les informations de tranche du cache mémoire.
Astuce : Vous pouvez lire "Comment JuiceFS stocke les fichiers" pour savoir ce que sont les morceaux et les tranches.
Par défaut, pour un fichier dont les métadonnées ont été mises en cache en mémoire, si aucun processus n'y a accédé pendant plus d'une heure, tout son cache de métadonnées sera automatiquement supprimé.
cache de données
JuiceFS fournit également divers mécanismes de mise en cache des données pour améliorer les performances, notamment le cache de page dans le noyau et le cache local du nœud où se trouve le client.
cache de données du noyau
Remarque : Cette fonctionnalité nécessite JuiceFS version 0.15.0 et supérieure.
Pour un fichier qui a été lu, le noyau mettra automatiquement son contenu en cache, puis ouvrira le fichier. Si le fichier n'a pas été mis à jour (c'est-à-dire que le mtime n'a pas été mis à jour), le fichier peut être lu directement à partir du cache dans le noyau pour obtenir les meilleures performances. Grâce au cache du noyau, les lectures répétées du même fichier dans JuiceFS peuvent être très rapides, avec une latence aussi faible que quelques microsecondes et un débit en Gio par seconde.
Le client JuiceFS n'a pas activé la fonction de cache en écriture du noyau par défaut. À partir du noyau Linux 3.15, FUSE prend en charge le "mode cache en écriture", ce qui signifie que les appels write()système . Vous pouvez activer le mode cache en écriture en définissant l' -o writeback_cacheoption . Il est recommandé d'activer cette option de montage lorsque de très petites données (par exemple environ 100 octets) doivent être écrites fréquemment.
Cache de lecture client
Le client JuiceFS pré-lit automatiquement les données dans le cache en fonction du mode de lecture, améliorant ainsi les performances des lectures séquentielles. Par défaut, lors de la lecture des données, 1 bloc est simultanément prérécupéré et mis en cache localement. Le cache local peut être configuré dans n'importe quel système de fichiers local basé sur un disque dur, un SSD ou une mémoire.
Le cache local peut être ajusté avec les options suivantes lors du montage du système de fichiers :
--prefetch value 并发预读 N 个块 (默认: 1)
--cache-dir value 本地缓存目录路径；使用冒号隔离多个路径 (默认: "$HOME/.juicefs/cache" 或 "/var/jfsCache")
--cache-size value 缓存对象的总大小；单位为 MiB (默认: 1024)
--free-space-ratio value 最小剩余空间比例 (默认: 0.1)
--cache-partial-only 仅缓存随机小块读 (默认: false)
De plus, si vous souhaitez stocker le cache local de JuiceFS en mémoire, il existe deux façons, l'une consiste à le --cache-dirdéfinir sur memory, l'autre à le définir sur /dev/shm/<cache-dir>. La différence entre les deux méthodes est que la première effacera les données mises en cache après avoir remonté le système de fichiers JuiceFS, tandis que la seconde les conservera, et il n'y a pas beaucoup de différence entre les deux en termes de performances.
Le client JuiceFS écrira les données téléchargées depuis le stockage d'objets (y compris les données nouvellement téléchargées de moins de 1 taille de bloc) dans le répertoire de cache aussi rapidement que possible sans compression ni cryptage. Étant donné que JuiceFS génère des noms uniques pour tous les objets de bloc écrits dans le magasin d'objets et que tous les objets de bloc ne seront pas modifiés, il n'est pas nécessaire de s'inquiéter de l'invalidation des données en cache lorsque le contenu du fichier est mis à jour.
Lorsque l'espace de cache atteint la limite supérieure (c'est-à-dire que la taille du cache est supérieure ou égale à --cache-size) ou que le disque est plein (c'est-à-dire que la proportion d'espace libre sur le disque est inférieure à celle --free-space-ratio), il sera automatiquement nettoyé. La règle actuelle consiste à nettoyer d'abord les fichiers peu consultés en fonction de l'heure d'accès.
La mise en cache des données peut améliorer efficacement les performances de lecture aléatoire.Pour les applications nécessitant des performances de lecture aléatoire plus élevées, telles que Elasticsearch et ClickHouse, il est recommandé de définir le chemin du cache sur un support de stockage plus rapide et d'allouer un espace de cache plus important.
Cache en écriture client
Lors de l'écriture de données, le client JuiceFS mettra les données en cache dans la mémoire close(), fsync()et les données ne seront pas téléchargées vers le stockage d'objets jusqu'à ce qu'un morceau soit rempli ou forcé par ou . Lors de l'appel fsync()de ou close(), le client attend que les données soient écrites dans le magasin d'objets et notifie le service de métadonnées avant de revenir, garantissant ainsi l'intégrité des données.
Dans certains cas, si le stockage local est fiable et que les performances d'écriture du stockage local sont nettement meilleures que celles de l'écriture réseau (comme un disque SSD), les performances d'écriture peuvent être améliorées en activant le téléchargement asynchrone des données, de sorte que l' close()opération n'attend pas que les données soient écrites dans le magasin d'objets, mais revient lorsque les données sont écrites dans le répertoire de cache local.
La fonctionnalité de téléchargement asynchrone est désactivée par défaut et peut être activée avec les options suivantes :
--writeback 后台异步上传对象 (默认: false)
Lorsqu'un grand nombre de petits fichiers doivent être écrits dans un court laps de temps, il est recommandé d'utiliser le --writebackparamètre pour monter le système de fichiers afin d'améliorer les performances d'écriture. Une fois l'écriture terminée, vous pouvez envisager d'annuler cette option et de remonter pour obtenir une plus grande fiabilité des données écrites ultérieures. De plus, il est également recommandé d'activer les scénarios qui nécessitent un grand nombre d'opérations d'écriture aléatoire, telles que les sauvegardes incrémentielles de MySQL --writeback.
Attention : Lorsque le téléchargement asynchrone est activé, c'est-à-dire
--writebacklorsque , ne supprimez pas<cache-dir>/<UUID>/rawstagingle contenu du répertoire, sinon cela entraînera une perte de données.
Lorsque le disque de cache est sur le point d'être plein, l'écriture des données sera suspendue et les données seront téléchargées directement vers le stockage d'objets à la place (c'est-à-dire que la fonction de cache d'écriture côté client sera désactivée). Lorsque la fonction de téléchargement asynchrone est activée, la fiabilité du cache lui-même est directement liée à la fiabilité de l'écriture des données. Elle doit être utilisée avec prudence dans les scénarios nécessitant une fiabilité élevée des données.
Résumer
Enfin, partagez une question que les utilisateurs posent souvent ** "Pourquoi la taille du cache est-elle définie sur 50 Gio, alors qu'elle occupe en réalité 60 Gio d'espace ?"**
Pour la même quantité de données mises en cache, il existe différentes règles de calcul de capacité sur différents systèmes de fichiers. JuiceFS est actuellement estimé en accumulant la taille de tous les objets mis en cache et en ajoutant une surcharge fixe (4 Ko), qui n'est pas exactement la même que la valeur obtenue par la ducommande . Pour éviter que le disque de cache ne soit plein, lorsque le système de fichiers où se trouve le répertoire de cache manque d'espace, le client essaiera de réduire autant que possible l'utilisation du cache.
Grâce à l'introduction ci-dessus, nous avons une meilleure compréhension du principe du mécanisme de mise en cache de JuiceFS. JuiceFS lui-même, en tant que système de fichiers sous-jacent, fournit divers mécanismes de mise en cache, y compris le cache de métadonnées, le cache de lecture et d'écriture de données, etc., pour garantir au maximum la cohérence des données. J'espère que vous pourrez mieux appliquer JuiceFS grâce à la compréhension de cet article.
Lecture recommandée : Zhihu x JuiceFS : Utilisation de JuiceFS pour accélérer le démarrage du conteneur Flink
Si cela vous est utile, veuillez suivre notre projet Juicedata/JuiceFS ! (0ᴗ0✿)