MetaDB repense les bases autour des métadonnées de fichiers
MetaDB: Putting File-System Structure Back into Distributed Databases · arXiv:2610.32247
En termes simples
Les systèmes de fichiers organisent les fichiers et les dossiers dans des répertoires. Une base de données généraliste peut répartir les enregistrements liés à un répertoire sur plusieurs machines, faire entrer en concurrence de nombreuses modifications d’un même enregistrement parent ou ralentir l’affichage du contenu d’un dossier après de nombreuses suppressions.
MetaDB est une base distribuée conçue autour de ces usages. Elle garde ensemble les données d’un répertoire et traite certaines mises à jour de façon asynchrone.
Lors d’un test de créations simultanées de dossiers dans un même répertoire, cette méthode de mise à jour a atteint un débit 10,7 fois supérieur à celui des transactions fondées sur des verrous, dans les conditions testées.
La recherche
Les systèmes de fichiers créent et suppriment des entrées par l’intermédiaire des répertoires, mais une base généraliste peut disperser les enregistrements liés et imposer une coordination stricte pour des mises à jour qui pourraient être différées.
Une base conçue autour de ces usages peut-elle mieux gérer la contention dans les répertoires et les parcours après de nombreuses suppressions ?
MetaDB adapte le placement des données et le traitement des mises à jour à la structure des répertoires et aux besoins des métadonnées, puis teste cette conception sous contention, lors de suppressions et en production.
Dans un test sur un cluster de production, les auteurs ont utilisé mdtest pour exécuter cinq opérations sur les métadonnées avec MetaDB et une base généraliste sur un cluster comptant 10 nœuds principaux. Avec 20 clients, chacun exécutant 50 threads et envoyant 2 000 requêtes, MetaDB a atteint, pour les cinq opérations, un débit de 2,2 à 4,1 fois celui de GP-DB. Le test indique donc un débit supérieur dans ces conditions.
Ce résultat appuie l’intérêt d’adapter la conception d’une base aux charges de travail sur les métadonnées. Les observations distinctes de latence en production ne permettent toutefois pas d’isoler l’effet de la base, car les clusters comparés différaient nettement par leur échelle.
Les observations de latence en production rapportées proviennent de deux clusters de tailles différentes : GP-DB comptait 4 nœuds principaux gérant 1 milliard de fichiers et de répertoires, tandis que MetaDB comptait 50 nœuds gérant 50 milliards d’éléments.
Les auteurs précisent que ces observations ne constituent pas une comparaison stricte des performances.
Ce que montrent les preuves
- Une base pour les métadonnées
MetaDB est une base distribuée qui tient compte des métadonnées et sert de couche commune aux systèmes de stockage de Baidu.
L’article examine comment gérer les métadonnées des systèmes de fichiers lorsque la structure des répertoires, les besoins de cohérence des mises à jour et les habitudes de suppression diffèrent des hypothèses des bases généralistes.
- Les mises à jour se disputent le répertoire
Un test illustre le problème de contention : dans le système précédent, le débit de création est passé d’environ 60 000 requêtes par seconde sans contention à environ 6 000 lorsque toutes les requêtes ciblaient un même répertoire.
Les requêtes se disputaient alors la mise à jour du même enregistrement de répertoire parent, ce qui a motivé une méthode permettant de traiter ces mises à jour sans verrouiller chacune d’elles au premier plan.
- L’agrégation réduit la contention
Pour des requêtes mkdir simultanées dans un même répertoire, les auteurs ont comparé des transactions fondées sur des verrous à une agrégation asynchrone. Chaque client envoyait quatre requêtes simultanées, tandis que le nombre de clients augmentait.
Dans cette expérience, l’agrégation a atteint un débit 10,7 fois supérieur à celui de l’exécution avec verrous, ce qui appuie cette approche pour le schéma de contention testé.
- Résultats sur le stockage et en production
Un test distinct sur les suppressions a comparé quatre configurations de stockage pendant des suppressions massives, avec une liste de dossiers exécutée en parallèle. La configuration associant MVCC en mémoire et compaction tenant compte de la localité a atteint une latence maximale de liste de 0,7 seconde, inférieure et plus stable que celle des autres configurations testées.
Un test sur un cluster de production a aussi mesuré un débit supérieur à celui de GP-DB pour cinq opérations sur les métadonnées, dans le cadre de cet essai.
Détails
- Auteurs de l’article original
- Zebin Ren, Biao Cao, Kang Chen, Zhihui Yin, Qiushi Chen
- Soumis à arXiv
- Licence
- CC BY 4.0