Qual è il modo migliore per lavorare con grandi database in Java a seconda del contesto?

Question

Qual è il modo migliore per lavorare con grandi database in Java a seconda del contesto?

#1 da (1 voti)
#2 da (1 voti)
#3 da (1 voti)
#4 da (0 voti)

5

Stiamo cercando di capire le migliori pratiche per lavorare con DB di grandi dimensioni in Java.

Quello che facciamo è un tipo di BI (business intelligence), cioè analizzare DB di grandi dimensioni e usarli per creare DB intermedi che rappresentano una conoscenza intelligente dei DB.

Attualmente stiamo usando JDBC e stiamo preformando le query usando un ResultSet.

Man mano che vengono creati sempre più dati, ci chiediamo se esistono modi più appropriati per analizzare e manipolare questi DB di grandi dimensioni:

Dobbiamo supportare la manipolazione "chunk" e non un intero DB in una volta (ad esempio, limite in JDBC, prestazioni molto scarse)
Non abbiamo bisogno di essere costantemente connessi poiché stiamo semplicemente tirando i risultati e creando nuove tabelle per conto nostro
Vogliamo capire le alternative JDBC, rispetto a vantaggi e svantaggi.
Se pensi che JDBC sia la strada da percorrere o meno, quali sono le migliori pratiche da seguire a seconda del contesto (ad es. per i DB di grandi dimensioni interrogati in blocchi)?

java database

posta gnat 02.03.2011 - 12:33

fonte

4 risposte

Leggi altre domande sui tag java database

Progettazione di database per dati polimorfici Eventi del dominio di fuoco dopo il completamento della transazione

score 1 · Answer 1

Non farlo. Se stai analizzando molti dati, fallo nel database.

Procedure memorizzate, tabelle temporanee, ecc.

Sono dati, e questo è ciò che un database è buono. Usa java per inviare le richieste e leggere i risultati. Consenti al DBMS di gestire i dati, poiché si tratta di un sistema di gestione del database.

score 1 · Answer 2

Ok. Elaborerò.

Fammi indovinare che estrai i dati dal DB, li attacchi in oggetti java, modifichi gli oggetti java e poi li salvi nel database? Questo è OK in una certa misura ... ma per grandi quantità di dati non lo è. Diciamo che vuoi disabilitare tutti gli utenti che vivono nello stato del Maryland. È possibile estrarre TUTTE le informazioni che non sono nemmeno utilizzate nell'oggetto java (nome, data di nascita, ecc.) E aggiornare OGNI campo di quell'utente, anche se non è stato modificato. Questo è OK per le modifiche a record singoli, non per l'elaborazione massiccia di batch di milioni di righe. Considera invece [aggiorna stato impostato dipendente = 'disabilitato' dove stato = 'maryland'].

crea una tabella di esempio, riempila con 10 milioni di righe di dati falsi. Confronta le prestazioni del materiale di caricamento in oggetti java rispetto a semplici aggiornamenti SQL basati su set.

score 1 · Answer 3

Sì, se la tua base dati è grande, puoi utilizzare il partizionamento per archiviare questi dati. E come detto sopra, non eseguire una singola query per recuperare dati per operazioni di confronto o analisi di piccole dimensioni.

Dividi la tua logica in modo tale che i criteri di filtro facili gestiti da stored procedure e query stessa e solo l'algoritmo complesso che potrebbe non essere supportato da query SQL o procedura supportata dovrebbe essere fatto con java dopo il recupero dei record.

score 0 · Answer 4

Strumenti aziendali come IBM InfoSphere fanno esattamente ciò che hai fatto con la connessione JDBC. Ho toccato il loro studio IBM DataStage per un po ', l'ho visto.

Il mio consiglio è di progettare lo schema dei grandi dati di origine in modo che quando si esegue la trasformazione dei dati intermedi si possa scrivere il progresso (usando una colonna), in modo che l'attività più grande possa essere suddivisa in attività più piccole basate su valori della colonna di progresso. Diciamo che uno recupera recupera 20000 righe, segnando l'offset per recuperi 2, ecc ...

Vorrei fare più java possibile a causa della pletora di modi in cui è possibile accedere, eseguire il debug quando qualcosa va storto. Se ti affidi troppo al DB, non penso che il debug e la lettura dei log sarebbero così comodi.