Utilizzo di JDBC per leggere in modo asincrono una tabella Oracle di grandi dimensioni

Question

Utilizzo di JDBC per leggere in modo asincrono una tabella Oracle di grandi dimensioni

#1 da (1 voti)

1

Quali strategie possono essere utilizzate per leggere ogni riga in una grande tabella Oracle , solo una volta , ma il più velocemente possibile con JDBC & Java?

Considera che ogni riga ha quantità non banali di dati (30 colonne, incluso testo di grandi dimensioni in alcune colonne).

Alcune strategie che posso pensare sono:

Discussione singola e tabella di lettura. (Troppo lento, ma elencato per chiarezza)
Leggi gli ID in ConcurrentLinkedQueue, utilizza i thread per consumare code e query per ID in batch.
Leggi gli ID in una coda JMS, usa gli impiegati per consumare la coda e eseguire query per ID in batch.

Quali altre strategie potrebbero essere utilizzate?

Ai fini di questa domanda, supponiamo che l'elaborazione delle righe sia gratuita.

java performance oracle jdbc

posta Ben George 26.04.2014 - 11:45

fonte

1 risposta

Leggi altre domande sui tag java performance oracle jdbc

Strategia di versionamento per JAR di interfacce di servizio Algoritmo per creare permutazioni per un dato alfabeto basato su un numero di sequenza

score 1 · Answer 1

La prima cosa è quanto velocemente hai bisogno che sia? Si dovrebbe essere consapevoli di non entrare nella zona di "ottimizzazione prematura".

Il primo suggerimento per chiarezza è aumentare jdbc_batch_size. Se il tuo database Oracle si trova su un host diverso, vedrai un aumento delle prestazioni su tutti i tuoi suggerimenti.

È possibile implementare il paging per dividere il set di dati in più pagine, quindi utilizzare i suggerimenti

Leggi l'intera riga / pagina in un ConcurrentLinkedQueue, utilizza i thread per consumare la coda (evita di dover ri-interrogare in base all'ID a spese dell'utilizzo di più memoria)
Un approccio simile può essere preso per il suggerimento JMS

Un altro suggerimento, anche se non sono sicuro che funzioni, è utilizzare l'API Java Streams ed elaborare il ResultSet. Il codice per questo sarà probabilmente più conciso, quindi sarebbe un vantaggio. L'unico svantaggio è che potresti non ottenere ResultSet in parallelo (vedi questo e questo per alcuni approfondimenti).