Come ridurre la dimensione del set di dati Jena con supporto TDB?

Question

Sto lavorando con un semplice set di dati Jena, che ha un solo file RDF da ~ 30 MB importato. Come parte dell'applicazione, sto tentando di consentire agli utenti di interrogare il grafico predefinito (o un grafico con nome) e di inserire i tripli risultanti dalla query in un nuovo grafico con nome. Per questo, sto usando un'istruzione CONSTRUCT per formare il set di risultati delle triple in formato RDF, quindi inserendo queste triple in un nuovo modello (utilizzando QueryExecution.execConstruct()) e aggiungendo questo modello al set di dati. Sembra che funzioni di nuovo, poiché il set di dati ottiene un nuovo nodo grafico e le dimensioni del disco della cartella del database TDB aumentano di dimensioni.

Il problema si presenta quando provo a rimuovere un grafico con nome dal set di dati. Usando il metodo removeNamedName ("graphName") di Dataset, rimuovo il modello dal set di dati. Le domande future sul nome di questo modello rivelano che è stato rimosso con successo. Tuttavia, le dimensioni del disco della cartella del database TDB rimangono delle stesse dimensioni, anche dopo la sincronizzazione e l'uscita.

In un primo momento ho pensato che forse il database stava solo contrassegnando lo spazio dei file cancellati come libero in modo che potesse essere sovrascritto quando arrivavano nuovi dati, ma questo non sembra essere il caso. Se elimino un grafico con nome e lo sostituisco immediatamente dopo lo stesso programma, la cartella non sembra crescere, ma se aggiungo un nuovo grafo chiamato ed lo elimini nella stessa esecuzione, la dimensione della cartella diventa più grande e il modello la rimozione non libera la memoria, il che significa che dopo alcune sessioni la cartella del database è cinque o dieci volte la sua dimensione originale senza contenere altri dati.

Qualsiasi intuizione o aiuto sarebbe grandioso, grazie ancora.

Answer 1

È possibile ottenere ulteriori informazioni chiedendo sulla mailing list Jena (users@jena.apache.org) ma cercherò di rispondere. Potresti anche dare un'occhiata alla pagina TDB Architecture sul sito web.

TDB memorizza i dati costruendo quella che definisce una tabella dei nodi che mappa i nodi RDF in ID di intero a 64 bit e viceversa. Quindi crea indici separati usando questi ID interi che consentono di eseguire le varie scansioni del database necessarie per rispondere alle query SPARQL.

L'aggiunta di dati potenzialmente aggiunge voci a entrambe queste strutture (tabella dei nodi e indici) ma la rimozione dei dati rimuove solo i dati dagli indici. Di conseguenza, nel tempo la tabella dei nodi continuerà a crescere anche se elimini dati vecchi perché non vengono eliminati dalla tabella dei nodi.

Le ragioni alla base di questa pratica sono due:

1. Gli ID interi in parte codificano gli offset di file in modo che il ID di nodo di ricerca è la scansione di un file veloce quindi come i dati vengono cancellati non è possibile eliminare le parti del nodo tabella senza dover riscrivere tutti gli ID dei nodi, ovvero la tabella dei nodi nell'ID -> la direzione del nodo è un file sequenziale (aiuta a rendere gli inserimenti molto veloci)
2. Quando i dati vengono cancellati non si sa se un nodo viene usato più volte senza fare una scansione completa del database. Pertanto non è possibile stabilire se una voce della tabella dei nodi debba essere eliminata in primo luogo. L'unico modo possibile per farlo sarebbe implementare uno schema completo di conteggio dei riferimenti che di per sé aggiungerebbe complessità al sistema e rallenterebbe le aggiunte e le eliminazioni.

responsabilità - Sono un committer sul progetto Jena ma non hanno mai fatto alcun lavoro personalmente sulla componente TDB quindi questo rispecchia la mia migliore comprensione e non può essere del tutto precisa.