[Jena] [TDB] Espace disque (comme Vacuum) ? [Résolu]

[teroux]

Bonjour,
J'ai remarqué dans mes Tests que la taille de l’entrepôt de données sur le disque ne diminue pas. C'est à dire que si j'ajoute 500k triplets et qu'ensuite je les supprime, l'espace disque (taille du dossier) a bien augmenté chez moi +125 mo un peu prêt mais n'a pas diminué ensuite.
Une discussion similaire ici, ou quelqu'un explique le pourquoi : http://stackoverflow.com/questions/1...d-jena-dataset.

Ma question, car après de nombreuses recherches je n'ai pas trouvé la réponse : Est'il possible comme sur une base postgre par exemple de faire un Vacuum et de libérer l'espace disque de cet entrepôt de triples ?
Car je compte l'utiliser dans une application professionnelle et je ne trouve pas cela concevable que l'espace disque alloué augmente de manière croissante quelque soit les modifications.

Merci d'avance pour votre aide et désolé si je suis passé à coté de la réponse dans mes recherches sur internet ou sur les différentes mailing list de jena.

[Sapience]

Ca ne va sûrement pas t'aider mais je ne crois pas que ce soit possible (de ce que je comprends, mais je ne parle pas par expérience). Je sais pas contre que BigData fonctionne de la même façon en mode "journal", sans libérer la place disque, donc ce mode de stockage doit avoir ses raisons et apporter ses avantages.

Si tu dois importer 500k triples et les supprimer après, pourquoi ne pas plutôt recréer un nouveau model dans un autre répertoire, ce qui te permettrait de libérer la place disque du premier modèle qui contenait tes 500k triples ?

Une autre réponse pourrait être "boaf, de toutes façons, maintenant vu la taille des disques, 1 Go de plus ou de moins, ce n'est pas bien méchant..."

Mais ça m'intéresse d'avoir ton retour d'expérience là-dessus si tu as trouvé une solution adéquate.

[teroux]

Alors Pour ceux que cela intéresse voici la conversation avec "Andy" sur la mailing list de JENA.
En conclusion, avec un serveur sparql de type fuseki, dans le cas d'une supression de triples dans l'entrepôt de données, l'espace disque reste inchangé mais sera réutilisé par la suite.
Il conclut aussi que la plupart des gros entrepôts de données ont plus une vocation à grandir qu'à diminuer.

>>> Hi,
>>> I'm a new user of Jena and i'm french so sorry for my english !
>>> I noticed the same thing as him :
>>> http://stackoverflow.com/questions/1...d-jena-dataset
>>>
>>> ("I remove the model from the dataset. Future queries over that model
>>> name reveal that it has successfully been removed. However, the disk
>>> size of the TDB database folder remains the same size, even after
>>> syncing and quitting.")
>>> I wanna know if throw the API or a command line we can "clear" the
>>> repository size.
>>> Because that repository will be use in an professionnal and i do not
>>> want the size on disk stay the same if i delete some triple or graph.
>>>
>>> Thanks for your help.
>>> Sorry for my english, and sorry if i didn't find the solution by my own.
>>> Regards.
>>> A.
>>>
>>
>> No - there isn't a way. The free space is left in the files for later
>> reuse (caveat that restarting causes some of the space to become
>> permanently inaccessible currently).
>>
>> The way to do it is to dump (to NQuads) and restore.
>>
>> Or if it's the whole database, release it from the StoreConnection and
>> delete the files. Except for Windows-64 where there is a long
>> standing Java issue with not being able to release mmap segments.
>>
>> Andy
>>
>>
> Hi andy,
>
> Thanks for your response.
>
> Just to make sure i understand correctly, i have to clean my repository
> by my own
> [/The way to do it is to dump (to NQuads) and restore. Or if it's the
> whole database, release it from the StoreConnection and delete the
> files/] to avoid the disk space use by jena TDB directory grown up
> exponentially if many update are made by the differents clients of my
> application.

If it's a server like Fuseki running, space is reused so there isn't a leak. There is a free block chain but it's not preserved (currently) across restarts of TDB.

> Just for information, my store will contains tens of thousands of triple.

That that large.

> People managing store with billions of triple do the same way to avoid
> this ?

Most uses are not restarting the database repeatedly so they do not encounter the problem. And, realistically, database grow rather than shrink over time.

Andy

>
> Thanks for your time.
>
> Aurelien.