MetaDB ripensa i database intorno ai metadati dei file system
MetaDB: Putting File-System Structure Back into Distributed Databases · arXiv:2610.32247
In parole semplici
I file system organizzano file e cartelle in directory. Un database generalista può distribuire su più macchine i record collegati a una directory, far competere molte modifiche per lo stesso record della directory padre o rallentare l’elenco dei file dopo grandi quantità di eliminazioni.
MetaDB è un database distribuito progettato intorno a questi schemi. Tiene insieme i dati delle directory e gestisce alcune modifiche in modo asincrono, cioè senza aspettare che siano tutte completate nel percorso principale della transazione.
In un test di creazione concorrente di cartelle nella stessa directory, questo metodo ha raggiunto un throughput 10.7 volte superiore alle transazioni basate su lock, nelle condizioni provate.
La ricerca
I file system creano e rimuovono elementi attraverso le directory, ma un database generalista può distribuire i record collegati su macchine diverse e richiedere un coordinamento rigoroso per aggiornamenti che potrebbero essere rinviati.
Un database progettato intorno a questi schemi può gestire con maggiore efficienza la contesa sulle directory e le scansioni dopo molte eliminazioni?
MetaDB adatta la collocazione dei dati e la gestione degli aggiornamenti alla struttura delle directory e alle esigenze dei metadati, poi valuta il progetto con carichi di lavoro caratterizzati da contesa, eliminazioni e condizioni di produzione.
In un test su cluster di produzione, gli autori hanno usato mdtest per eseguire cinque operazioni sui metadati in MetaDB e in un database generalista su un cluster con 10 nodi backend. Con 20 client, 50 thread ciascuno e 2.000 richieste per client, MetaDB ha raggiunto, sulle cinque operazioni, un throughput da 2.2 a 4.1 volte superiore a quello di GP-DB. Il risultato mostra un throughput più elevato in quel test.
Questo dato sostiene l’idea di adattare la progettazione dei database ai carichi di lavoro sui metadati. Le osservazioni separate sulla latenza in produzione, invece, non isolano l’effetto del database, perché i cluster differivano notevolmente per dimensioni.
Le osservazioni sulla latenza in produzione provengono da due cluster di dimensioni diverse: GP-DB aveva 4 nodi backend che gestivano 1 miliardo di file e directory, mentre MetaDB aveva 50 nodi che ne gestivano 50 miliardi.
Gli autori precisano che queste osservazioni non costituiscono un confronto rigoroso delle prestazioni.
Cosa mostrano le prove
- Un database per i metadati
MetaDB è un database distribuito che tiene conto dei metadati e che Baidu usa come livello condiviso per i propri sistemi di archiviazione.
Il documento esamina come gestire i metadati dei file system quando la struttura delle directory, le esigenze di coerenza degli aggiornamenti e i modelli di eliminazione differiscono dalle ipotesi dei database generalisti.
- Contesa sugli aggiornamenti delle directory
Un test mostra il problema della contesa: nel sistema precedente, il throughput delle operazioni di creazione è sceso da circa 60.000 query al secondo senza contesa a circa 6.000 quando tutte le richieste riguardavano una sola directory.
Le richieste competevano per aggiornare lo stesso record della directory padre; questo ha motivato un metodo per gestire tali aggiornamenti senza bloccarli uno per uno nel percorso principale.
- L’aggregazione riduce la contesa
Per le richieste mkdir concorrenti nella stessa directory, gli autori hanno confrontato transazioni basate su lock e aggregazione asincrona. Ogni client inviava quattro richieste concorrenti, mentre aumentava il numero di client.
In questo esperimento, l’aggregazione ha raggiunto un throughput 10.7 volte superiore all’esecuzione basata su lock: un riscontro a favore di questo approccio nello schema di contesa testato.
- Risultati su archiviazione e produzione
Un test separato sulle eliminazioni ha confrontato quattro configurazioni di archiviazione durante cancellazioni di massa, con un elenco di cartella eseguito in parallelo. La configurazione che combinava MVCC in memoria e compattazione consapevole della località ha registrato una latenza massima di elenco di 0.7 secondi, inferiore e più stabile rispetto alle altre configurazioni testate.
Anche un test su un cluster di produzione ha rilevato un throughput superiore a GP-DB su cinque operazioni sui metadati, entro i limiti di quel test.
Dettagli
- Autori del paper originale
- Zebin Ren, Biao Cao, Kang Chen, Zhihui Yin, Qiushi Chen
- Inviato ad arXiv
- Licenza
- CC BY 4.0