Le système de fichiers est notre forme de stockage commune, qui se compose principalement de deux parties : les données et les métadonnées. Parmi eux, les données sont le contenu spécifique du fichier, qui est généralement affiché directement à l'utilisateur ; et les métadonnées sont les données décrivant les données, qui sont utilisées pour enregistrer les attributs du fichier, la structure du répertoire, l'emplacement de stockage des données, etc. De manière générale, les métadonnées ont des caractéristiques très particulières, c'est-à-dire qu'elles occupent moins d'espace mais sont consultées très fréquemment.
Dans les systèmes de fichiers distribués d'aujourd'hui, certains (tels que S3FS) gèrent les métadonnées et les données de manière unifiée pour simplifier la conception du système, mais l'inconvénient est que certaines opérations de métadonnées entraîneront un décalage évident pour les utilisateurs, tels que des répertoires lsvolumineux etc. Plus de systèmes de fichiers choisiront de gérer les deux séparément et d'effectuer une optimisation ciblée en fonction des caractéristiques des métadonnées. JuiceFS adopte cette conception et son schéma d'architecture est le suivant :
Parmi eux, le moteur de métadonnées doit être une base de données capable de prendre en charge les opérations de transaction, et le moteur de données utilise généralement le stockage d'objets . Jusqu'à présent, JuiceFS a pris en charge plus de 10 moteurs de métadonnées et plus de 30 moteurs de données.
Lors de l'utilisation de JuiceFS, les utilisateurs peuvent librement choisir des composants matures pour agir comme ces deux moteurs afin de faire face aux environnements d'entreprise riches et changeants et aux exigences de stockage de données. Cependant, pour les nouveaux utilisateurs, confrontés à plus de choix, cela amène également une question : quelle base de données est la plus appropriée à choisir comme moteur de métadonnées dans mon scénario ? Cet article présentera les types de moteurs de métadonnées que JuiceFS peut utiliser, ainsi que leurs avantages et inconvénients du point de vue de la conception du produit.
01-Type de moteur de métadonnées JuiceFS
Il existe trois catégories de moteurs de métadonnées actuellement pris en charge par JuiceFS.
Le premier est Redis . Redis est le premier moteur de métadonnées pris en charge par JuiceFS après son open source. Tout d'abord, Redis est assez rapide, ce qui est l'une des fonctionnalités importantes dont les moteurs de métadonnées doivent disposer ; deuxièmement, Redis a un large public et la plupart des utilisateurs ont une expérience pratique de Redis. JuiceFS prend également en charge les bases de données compatibles avec le protocole Redis, telles que KeyDB et Amazon MemoryDB.
Cependant, la fiabilité et l'évolutivité de Redis sont facilement limitées et ses performances sont médiocres dans certains scénarios avec des exigences élevées en matière de sécurité des données ou à grande échelle.Par conséquent, nous avons développé et pris en charge deux autres types de moteurs.
La seconde est la classe SQL . Tels que MySQL, MariaDB, PostgreSQL, etc., ils se caractérisent par une grande popularité et ont généralement une bonne fiabilité et évolutivité. De plus, la base de données embarquée SQLite est également prise en charge.
La dernière est la classe TKV (Transactional Key-Value Database) . Leurs interfaces natives sont relativement simples, elles sont donc plus personnalisables dans JuiceFS et ont généralement des performances plus élevées que les classes SQL. À l'heure actuelle, ce type de support inclut TiKV, etcd et BadgerDB intégré, etc. Le support de FoundationDB est également en cours de développement intensif.
Ce qui précède est une classification basée sur l'interface de protocole de JuiceFS lors de la connexion à la base de données. Il existe différentes bases de données dans chaque catégorie, et chaque base de données a ses propres caractéristiques. Ce qui suit compare plusieurs options couramment utilisées par les utilisateurs en fonction de ces caractéristiques.
Comparaison des moteurs de métadonnées
| Redis | MySQL/PostgreSQL | TiKV | etcd | SQLite/BadgerDB | |
|---|---|---|---|---|---|
| performance | haut | Faible | milieu | Faible | milieu |
| Évolutivité | Faible | milieu | haut | Faible | Faible |
| fiabilité | Faible | haut | haut | haut | milieu |
| disponibilité | milieu | haut | haut | haut | Faible |
| Popularité | haut | haut | milieu | haut | milieu |
Comme mentionné ci-dessus, le plus grand avantage de Redis est sa haute performance, car il s'agit d'une base de données à mémoire complète. À d'autres égards, il est médiocre.
En termes d'évolutivité, un seul Redis peut généralement prendre en charge environ 100 millions de fichiers. Lorsqu'il dépasse 100 millions, l'utilisation de la mémoire d'un seul processus Redis sera relativement importante et les performances de gestion diminueront également. La version open source de Redis prend en charge le mode cluster pour étendre la quantité totale de données qu'il peut gérer. Cependant, étant donné que Redis ne prend pas en charge les transactions distribuées en mode cluster, en tant que moteur de métadonnées JuiceFS, il n'y a toujours qu'un seul processus Redis disponible pour chaque JuiceFS. volume. , l'évolutivité d'un seul volume n'est pas beaucoup améliorée par rapport à un seul Redis.
Du point de vue de la fiabilité, Redis vide les données toutes les secondes par défaut, ce qui peut entraîner une petite perte de données en cas d'exception. En modifiant la configuration d'appendfsync en toujours, Redis peut être vidé après chaque demande d'écriture, de sorte que les performances de fiabilité des données sont améliorées, mais les performances diminueront.
En termes de disponibilité, le déploiement de nœuds de surveillance sentinelle Redis et de nœuds de secours peut sélectionner un nœud de secours pour fournir à nouveau des services après le raccrochage du nœud Redis principal, améliorant ainsi la disponibilité dans une certaine mesure. Cependant, Redis lui-même ne prend pas en charge un protocole de consensus distribué et ses nœuds de sauvegarde utilisent une sauvegarde asynchrone. Ainsi, bien que le nouveau nœud soit opérationnel, il peut y avoir des lacunes dans les données au milieu, ce qui entraîne des données incomplètes.
Les performances globales de MySQL et de PostgreSQL sont similaires. Ce sont tous des produits de base de données qui ont été vérifiés par un grand nombre d'utilisateurs pendant de nombreuses années, avec une bonne fiabilité et disponibilité, et une grande popularité. C'est juste que leurs performances sont moyennes par rapport aux autres moteurs de métadonnées.
TiKV était à l'origine le stockage sous-jacent de PingCAP TiDB, mais il a maintenant été séparé et est devenu un composant de base de données KV indépendant. D'après nos résultats de test, c'est un excellent choix pour le moteur de métadonnées JuiceFS. La fiabilité des données et la disponibilité des services ne sont pas plus faibles que MySQL, et ses performances et son évolutivité sont meilleures. Seulement en termes de popularité, il y a encore un écart entre lui et MySQL. D'après notre communication avec les utilisateurs, s'ils sont déjà des utilisateurs de TiKV ou de TiDB, ils préfèrent généralement utiliser TiKV comme moteur de métadonnées de JuiceFS au final. Mais s'ils ne connaissent pas TiKV auparavant, ils seront beaucoup plus prudents en acceptant un tel nouveau composant.
etcd est une autre base de données de type TKV. La raison de la prise en charge d'etcd est qu'il est très populaire dans les scénarios de conteneurisation. Fondamentalement, k8s utilise etcd pour gérer sa configuration. Utiliser etcd comme moteur de métadonnées de JuiceFS n'est pas un scénario particulièrement adapté. D'une part, ses performances sont moyennes, et d'autre part, il a des limites de capacité (2G par défaut, 8G maximum), et il sera difficile de l'étendre par la suite. Cependant, sa fiabilité et sa disponibilité sont très élevées et il est facile à déployer dans des scénarios conteneurisés. Par conséquent, si les utilisateurs n'ont besoin que d'un système de fichiers à l'échelle d'un million de fichiers, etcd reste un bon choix .
Enfin, il existe SQLite et BadgerDB, qui appartiennent respectivement à la classe SQL et à la classe TKV, mais l'expérience de leur utilisation est très similaire, car ce sont toutes des bases de données embarquées autonomes. Ce type de base de données se caractérise par des performances moyennes, mais une évolutivité et une disponibilité médiocres, car ses données sont en fait stockées dans le système local. Ils ont l'avantage d'être très faciles à utiliser, ne nécessitant que les propres binaires de JuiceFS et aucun composant supplémentaire. Les utilisateurs peuvent utiliser ces deux bases de données dans certains scénarios spécifiques ou lors de la réalisation de tests fonctionnels simples.
02- Résultats des tests de performance d'un moteur typique
Nous avons effectué des tests de performances typiques du moteur et enregistré les résultats dans ce document . L'un des résultats les plus directs du test de l'interface source est à peu près : Redis > TiKV (3 copies) > MySQL (local) ~= etcd (3 copies) , comme suit :
| Redis-Toujours | Redis-Everysec | TiKV | MySQL | etcd | |
|---|---|---|---|---|---|
| mkdir | 600 | 471 (0,8) | 1614 (2.7) | 2121 (3.5) | 2203 (3.7) |
| est mv | 878 | 756 (0,9) | 1854 (2.1) | 3372 (3.8) | 3000 (3.4) |
| est rm | 785 | 673 (0,9) | 2097 (2.7) | 3065 (3.9) | 3634 (4.6) |
| readdir_10 | 302 | 303 (1.0) | 1232 (4.1) | 1011 (3.3) | 2171 (7.2) |
| readdir_1k | 1668 | 1838 (1.1) | 6682 (4.0) | 16824 (10.1) | 17470 (10.5) |
| mknod | 584 | 498 (0,9) | 1561 (2.7) | 2117 (3.6) | 2232 (3.8) |
| créer | 591 | 468 (0,8) | 1565 (2.6) | 2120 (3.6) | 2206 (3.7) |
| Renommer | 860 | 736 (0,9) | 1799 (2.1) | 3391 (3.9) | 2941 (3.4) |
| dissocier | 709 | 580 (0,8) | 1881 (2,7) | 3052 (4.3) | 3080 (4.3) |
| chercher | 99 | 97 (1.0) | 731 (7.4) | 423 (4.3) | 1286 (13.0) |
| obtenir | 91 | 89 (1.0) | 371 (4.1) | 343 (3,8) | 661 (7.3) |
| setattr | 501 | 357 (0,7) | 1358 (2.7) | 1258 (2.5) | 1480 (3.0) |
| accès | 90 | 89 (1.0) | 370 (4.1) | 348 (3,9) | 646 (7.2) |
| setxattr | 404 | 270 (0,7) | 1116 (2.8) | 1152 (2.9) | 757 (1.9) |
| getxattr | 91 | 89 (1.0) | 365 (4.0) | 298 (3.3) | 655 (7.2) |
| supprimerxattr | 219 | 95 (0,4) | 1554 (7.1) | 882 (4.0) | 1461 (6,7) |
| listexattr_1 | 88 | 88 (1.0) | 374 (4.2) | 312 (3.5) | 658 (7.5) |
| listexattr_10 | 94 | 91 (1.0) | 390 (4.1) | 397 (4.2) | 694 (7.4) |
| lien | 605 | 461 (0,8) | 1627 (2.7) | 2436 (4.0) | 2237 (3.7) |
| lien symbolique | 602 | 465 (0,8) | 1633 (2.7) | 2394 (4.0) | 2244 (3.7) |
| écrire | 613 | 371 (0,6) | 1905 (3.1) | 2565 (4.2) | 2350 (3.8) |
| lire_1 | 0 | 0 (0.0) | 0 (0.0) | 0 (0.0) | 0 (0.0) |
| lire_10 | 0 | 0 (0.0) | 0 (0.0) | 0 (0.0) | 0 (0.0) |
- Le tableau ci-dessus enregistre la durée de chaque opération, plus la valeur est petite, mieux c'est ; le nombre entre parenthèses est le multiple de l'indice par rapport à Redis-toujours, et plus la valeur est petite, mieux c'est
- Always et Everysec sont des valeurs facultatives de l'élément de configuration Redis appendfsync, qui indiquent respectivement que chaque requête est vidée et chaque seconde est vidée
- On peut voir que lorsque Redis utilise everysec, ses performances sont meilleures, mais ce n'est pas très différent de toujours ; c'est parce que les performances IOPS du disque SSD local lui-même sur la machine AWS utilisée pour le test sont relativement élevées
- TiKV et etcd utilisent tous deux trois copies, tandis que MySQL est déployé sur une seule machine. Même ainsi, les performances de TiKV sont toujours supérieures à celles de MySQL, tandis qu'etcd est proche de MySQL.
Il convient de mentionner que les tests utilisent avant tout des configurations par défaut et qu'aucun réglage spécifique n'a été effectué pour chaque moteur de métadonnées. Les utilisateurs peuvent configurer et ajuster en fonction de leurs propres besoins et de leur expérience pratique lors de son utilisation, et les résultats peuvent être différents .
Un autre test a été effectué via l'outil de banc d'essai fourni avec JuiceFS, qui exécute l'interface du système d'exploitation pour lire et écrire des fichiers. Les résultats spécifiques sont les suivants :
| Redis-Toujours | Redis-Everysec | TiKV | MySQL | etcd | |
|---|---|---|---|---|---|
| Écrire un gros fichier | 565,07 Mio/s | 556,92 Mio/s | 553,58 Mio/s | 557,93 Mio/s | 542,93 Mio/s |
| Lire gros fichier | 664,82 Mio/s | 652,18 Mio/s | 679,07 Mio/s | 673,55 Mio/s | 672,91 Mio/s |
| Écrire un petit fichier | 102,30 fichiers/s | 105,80 fichiers/s | 95,00 fichiers/s | 87,20 fichiers/s | 95,75 fichiers/s |
| Lire petit fichier | 2200.30 fichiers/s | 1894,45 fichiers/s | 1394,90 fichiers/s | 1360,85 fichiers/s | 1017.30 fichiers/s |
| Fichier statistique | 11607.40 fichiers/s | 15032.90 fichiers/s | 3283.20 files/s | 5470.05 files/s | 2827.80 files/s |
| FUSE operation | 0.41 ms/op | 0.42 ms/op | 0.45 ms/op | 0.46 ms/op | 0.42 ms/op |
| Update meta | 3.63 ms/op | 3.19 ms/op | 7.04 ms/op | 8.91 ms/op | 4.46 ms/op |
从上表可以看到，读写大文件时使用不同的元数据引擎最后性能是差不多的。这是因为此时性能瓶颈主要在对象存储的数据读写上，元数据引擎之间虽然时延有点差异，但是放到整个业务读写的消耗上，这点差异几乎可以忽略不计。当然，如果对象存储变得非常快（比如都用本地全闪部署），那么元数据引擎的性能差异可能又会体现出来。另外，对于一些纯元数据操作（比如 ls，创建空文件等），不同元数据引擎的性能差别也会表现的比较明显。
03-引擎选型的考虑要素
根据上文介绍的各引擎特点，用户可以根据自己的情况去选择合适的引擎。以下简单分享下我们在做推荐时会建议用户考虑的几个要素。
评估需求：比如想使用 Redis，需要先评估能否接受少量的数据丢失，短期的服务中断等。如果是存储一些临时数据或者中间数据的场景，那么用 Redis 确实是不错的选择，因为它性能够好，即使有少量的数据丢失，也不会造成很大的影响。但如果是要存储一些关键数据， Redis 就不适用了。另外还得评估预期数据的规模，如果在 1 亿文件左右， Redis 可以承受；如果预期会有 10 亿文件，那么显然单机 Redis 是难以承载的。
评估硬件：比如能否连通外网，是使用托管的云服务，还是在自己机房内私有部署。如果是私有部署，需要评估是否有足够的硬件资源去部署一些相关的组件。无论是用哪一种元数据引擎，基本上都要求有高速的 SSD 盘去运行，不然会对其性能有比较大的影响。
评估运维能力，这是很多人会忽视的，但是在我们来看这应该是最关键的因素之一。对于存储系统来说，稳定性往往才是其上生产后的第一重点。用户在选择元数据引擎的时候，应该先想想自己对它是不是熟悉，在出现问题时，能否快速定位解决；团队内是否有足够的经验或精力去把控好这个组件。通常来说，我们会建议用户在开始时选择一个自己熟悉的数据库是比较合适的。如果运维人员不足，那么选择 JuiceFS 公有云服务也确实是个省心的选项。
最后，分享下社区在使用元数据引擎方面的一些统计数据。
- 目前为止， Redis 的使用者依然占了一半以上，其次是 TiKV 和 MySQL，这两类的使用者的数量占比在逐步增长。
- 在运行的 Redis 集群的最大文件数大概是在 1.5 亿，而且运行情况是比较稳定的，上文提到的推荐的 1 亿文件是建议值，并不是说无法超过 1 亿。
- 整体数量规模 Top3，都是使用的 TiKV 而且都超过了 10 亿文件数量。现在最大的文件系统的文件数量是超了 70 亿文件，总容量超过了 15 PiB，这也从侧面证明了 TiKV 在作为元数据引擎时的扩展能力。我们自己内部测过使用 TiKV 作为元数据引擎存储 100 亿文件，系统仍能稳定地运行。所以如果你的整个集群预期的规模会非常大，那么TiKV 确实是一个很好的选择。
04- 元数引擎迁移
文章的最后，为大家介绍元数据引擎迁移。 随着用户业务的发展，企业对元数据引擎的需求会发生变化，当用户发现现有的元数据引擎不合适了，可以考虑将元数据迁移到另一个引擎中。 我们为用户提供了完整的迁移方法，具体可以参考这个文档。
这个迁移方法有一定的限制，首先只能迁移到空数据库，暂时无法将两个文件系统直接合在一起；其次，需要停写，因为数据量会比较大的情况下，很难在线将元数据完整的迁移过来。要做到这点需要加许多限制，从实测来看速度会非常慢。因此，把整个文件系统停掉再去做迁移是最稳妥的。如果说实在需要有一定的服务提供，可以保留只读挂载，用户读数据并不会影响整个元数据引擎迁移的动作。
虽然社区提供了全套的迁移方法，但是还是需要提醒用户，尽量提前对数据量的增长做好规划，尽量不做迁移或尽早迁移。当要迁移的数据规模很大时，耗时也会变长，期间出问题的概率也会变大。
如有帮助的话欢迎关注我们项目 Juicedata/JuiceFS 哟！ (0ᴗ0✿)