Parser XML Java per file enormi

Question

Ho bisogno di un parser xml per analizzare un file di circa 1,8 gb.
Quindi il parser non dovrebbe caricare tutto il file in memoria.

Qualche suggerimento?

Answer 1

A parte l'analisi SAX consigliata, è possibile utilizzare l'API StAX (una specie di evoluzione SAX), inclusa nel JDK (pacchetto javax.xml.stream).

• StAX Progetto casa: http://stax.codehaus.org/Home
• Breve introduzione: http://www.xml.com/pub/a/2003/09/17/stax.html
• Javadoc: https://docs.oracle.com/javase/8/docs/api/javax/xml/stream/package-summary.html

Answer 2

Utilizzare quasi qualsiasi SAXParser per lo streaming del file un po 'alla volta.

Answer 3

Riversare il file in un parser SAX e leggerlo in memoria in blocchi.

SAX ti dà un sacco di controllo ed essere guidato dagli eventi ha senso. L'api è un po 'difficile da controllare, devi prestare attenzione ad alcune cose come quando viene chiamato il metodo characters(), ma l'idea di base è scrivere un gestore di contenuto che viene chiamato quando l'inizio e la fine di ogni l'elemento xml è letto. In questo modo puoi tenere traccia dell'attuale xpath nel documento, identificare quali percorsi hanno i dati a cui sei interessato e identificare quale percorso segna la fine di un blocco che vuoi salvare, trasferire o elaborare.

Answer 4

Utilizzare un parser basato su SAX che presenta il contenuto del documento in un flusso di eventi.

Answer 5

Prova VTD-XML. Ho trovato che è più performante e, soprattutto, più facile da usare rispetto a SAX.

Answer 6

Come altri hanno già detto, utilizzare un parser SAX, in quanto è un parser di streaming. Usando i vari eventi, estrai le tue informazioni come necessario e poi, al volo, memorizza altrove (database, un altro file, cos'hai).

È possibile persino memorizzarlo in memoria se si ha veramente bisogno di un sottoinsieme minore o se si sta semplicemente riassumendo il file. Dipende dal caso d'uso, ovviamente.

Se si esegue lo spooling su un DB, assicurarsi di avere cura di rendere il processo riavviabile o altro. Molto può accadere in 1.8 GB che può fallire nel mezzo.

Answer 7

StAX API è più facile da trattare con rispetto a SAX. Ecco uno short tutorial

Answer 8

+1 per StaX. È più facile da usare rispetto a SaX perché non è necessario scrivere callback (in pratica si limitano a eseguire il ciclo su tutti gli elementi del tempo finché non si è terminato) e non ha (AFAIK) alcun limite per quanto riguarda la dimensione dei file che può elaborare .

Answer 9

Ho avuto un problema simile: ho dovuto leggere un intero file XML e creare una struttura dati in memoria. Su questa struttura dati (il tutto doveva essere caricato) ho dovuto fare varie operazioni. Molti elementi XML contenevano testo (che dovevo produrre nel mio file di output, ma non era importante per l'algoritmo).

In primo luogo, come suggerito qui, ho usato SAX per analizzare il file e creare la mia struttura dati. Il mio file era di 4 GB e avevo una macchina da 8 GB, quindi ho pensato che forse 3 GB del file fossero solo testo e java.lang.Probabilmente la stringa necessiterebbe di 6 GB per quei testi che usano il suo UTF-16.

Se la JVM occupa più spazio del computer con RAM fisica, la macchina si scambierà. Fare un segno + spazzare garbage collection comporterà l'accesso alle pagine in ordine casuale e anche gli oggetti che vengono spostati da un pool di oggetti a un altro, che in pratica uccide la macchina.

Così ho deciso di scrivere tutte le mie stringhe su un disco in un file (la FS può ovviamente gestire la scrittura sequenziale del 3GB bene, e quando la legge nel sistema operativo userà la memoria disponibile per una cache del file system ; potrebbero ancora esserci letture ad accesso casuale ma meno di un GC in java). Ho creato una piccola classe di supporto che è più che gradita scaricare se ti aiuta: StringsFile javadoc | Download ZIP.

StringsFile file = new StringsFile(); 
StringInFile str = file.newString("abc");  // writes string to file 
System.out.println("str is: " + str.toString()); // fetches string from file