Bonjour,  
 
Je dois réaliser en Java une petite api permettant de synchroniser des répertoires. Chaque fichiers contenu dans ces répertoires ont des métadonnées (vers qui il est synchronisé, son path, etc..) indispensable au moteur de synchro.  
 
J'ai d'abord stocké ces métadonnées sous forme d'arbre dans un fichier XML grâce à l'API jdom2 (certainement la plus simple api pour parser du xml en java), mais je me suis vite rendu compte que ce n'était pas fait pour ça (trop de ram consommée lorsque le nombre de fichiers deviens important - lorsque le fichier XML est grand).
J'ai ensuite essayé de créer un objet par fichier/dossier pour ensuite le sérialiser, mais ce n'est pas la bonne méthode non plus (trop d'objets sont créés, trop de ram/ressource cpu est utilisé).
 
J'ai essayé avec un system de cache (http://ehcache.org/), mais c'est pas top non plus, car de toute façon, il faut que je crée autant d'objets qu'il y a de fichiers/dossiers.
 
J'ai deux autres idées:  

• utiliser une base de donnée pour stocker mes métadonnées
• stocker ces dernières grâce à un parseur json ou bien xml plus performant que jdom2

Si vous avez d'autres idées je suis preneur  

La base de donnée s'impose d'elle meme dans ce genre de cas.
 
Je suis surpris par le "trop de ram consommée". Je vois pas trop comment un systeme de fichier avec des noms de fichiers et des données peut remplir ta RAM ?? Il y a tant de fichiers que ça ?? quelle taille atteint ton fichier ? je trouve ça étrange.
 
Sinon pour le débat json vs xml, oui il est temps d'arreter d'utiliser le xml pour passer à du json.

Je comprend pas ton volume de données. Si tu gères de la synchro / réplication, pour une arborescence donnée, tu ne stockes qu'une seule fois "vers qui il est synchronisé, son path" et tu déduit le reste de ton arborescence de base. T'as plus de détails sur tes metas ?
 
Sinon, parsing XML plus rapide et léger en RAM (mais plus de code) => SAX / StAX / Woodstox
Si tu pars sur une BDD locale, SQLite devrait suffire.

La taille du fichier XML n'est pas très grande (5-10Mo pour environ 30 000 fichiers), par contre la ram utilisé après parsing de ce fichier est (très) grande, environs 300-500Mo. De même lorsque j'utilise des objets java, mais ça c'est peut-être à cause des HashMap (utilisé pour enregistrer tout les objets (fichiers/dossiers) enfants d'un dossier et y accéder par son nom)
 

Oui j'ai plus de détail sur les méta, car dans mon api, un fichier peut être synchronisé vers plusieurs endroit, j'ai donc n paths de destinations. J'ai aussi la taille du fichier, sa date de dernière modif, et encore quelques autres méta.  C'est pas vraiment un système de synchro "standard"    
 

J'avais déja jeté un coup d'oeil à Woodstox, effectivement il faut écrire pas mal de code à coté, alors je pense partir sur une base de donnée. D’ailleurs ne serai-ce pas plus judicieux d'utiliser H2 (http://www.h2database.com/html/main.html) étant donnée qu'elle est écrite entièrement en java ? Coté perf elle à l'air pas mal

 
L'avantage de SQLite c'est qu'une base est un fichier. Ça va te faciliter la tâche côté structure, tu peux créer une base par répertoire synchronisé par exemple.
 

Tu devrais peut être ne pas parser tout le fichier XML d'un coup. Par exemple tu pourrais ne parser le XML que par groupe de 1000. Pour chaque groupe tu vérifie la synchro entre les dossiers, tu supprime les objets parser de ces 1000 fichiers (en mettant les pointeurs à null) puis tu synchro les 1000 suivants...etc.
 
La technique est peut être un peu bancal, je pense qu'il faut tester son efficacité mais elle évite de passer par une BDD.