2011-01-22 20 views
5

Ho un file xml di grandi dimensioni che contiene molti elementi secondari. Voglio poter eseguire alcune query xpath. Ho provato a utilizzare vtd-xml in java, ma a volte mi viene fuori un errore di memoria, perché l'xml è così grande da adattarsi alla memoria. Esiste un modo alternativo per elaborare xml di grandi dimensioni.Elaborazione di file xml di grandi dimensioni

+0

Perché il tag Python su questa domanda? Speri che le persone offrano soluzioni Python? – Spaceghost

+0

Si verificano errori di memoria durante l'analisi del documento o quando si provano le query xpath? Se il secondo, forse il problema è con le query xpath. In entrambi i casi, hai provato ad aumentare il valore di -Xmx per heap per JVM? – Spaceghost

+0

provare esteso vtd-xml e utilizzare l'opzione di mappatura della memoria –

risposta

2

è molto efficiente quando si lavora con file di grandi dimensioni

+1

Non è possibile utilizzare XPath con un flusso SAX diretto (a meno di ripetere l'analisi dell'intero file per ogni query). –

+0

@Glenn Maynard - ma sicuramente l'OP * deve * ripubblicare il file per ogni query (o batch di query). Il DOM è troppo grande per adattarsi alla memoria. –

2

Cosa stai cercando di fare in questo momento? Con il suono di esso si sta tentando di utilizzare un parser basato su DOM, che essenzialmente carica l'intero file XML in memoria come rappresentazione DOM. Se si ha a che fare con un file di grandi dimensioni, è preferibile utilizzare un parser SAX, che elabora il documento XML in modalità streaming.

Personalmente raccomando StAX per questo.

0

Hai usato VTD-xml standard vtd o esteso? Se usi XML esteso, hai la possibilità di usare la mappatura della memoria ... ci hai provato?

0

L'utilizzo di XPath potrebbe non essere una buona idea se si pianifica di compilare molte espressioni dinamicamente in un'applicazione longeva.

Non sono del tutto sicuro di come funziona la versione java di XPath, ma in .NET XPath compila un assembly dinamico quindi lo aggiunge al dominio dell'app. Gli usi successivi dell'espressione guardano l'assieme ora caricato in memoria.
In un caso, mentre stavo usando XPath, ho portato a una situazione in cui, a mio avviso, questo stesso tipo di meccanismo stava rallentando il riempimento della memoria simile a una perdita di memoria.

La mia teoria è che siccome ogni espressione è stata compilata utilizzando i valori dell'utente, ogni espressione compilata era probabilmente unica, quindi una nuova espressione è stata compilata e aggiunta al dominio dell'app.
Poiché è possibile rimuovere l'assembly dal dominio dell'app senza riavviare l'intero dominio dell'app, la memoria veniva consumata ogni volta che veniva valutata un'espressione e non poteva essere ripristinata. Di conseguenza, il codice stava perdendo memoria sotto forma di assembly in memoria e, dopo un po ', si conoscono i risultati.

Problemi correlati