Newsgroup: it.comp.java
Titolo: Interrogare 2 milioni di record

Salve a tutti,
per un progetto mi hanno dato da consultare un archivio di circa 2
milioni di righe e devo fare ricerche su un indice univoco. Non vorrei
usare un DB, perché i dati sono quelli, non cambiano mai, è uno
storico.
Dove posso mettere queste informazioni, per avere il massimo delle
performance? Avevo pensato a lucene, ma se esiste qualcosa di ancora
più snello, sarebbe meglio!
Qualcuno ha già avuto un'esperienza del genere???
Ciao, Davide.

 performance?
In un DB :)

 Qualcuno ha già avuto un'esperienza del genere???
Due milioni di record, se adeguatamente indicizzati, non sono tanti.
Lucene è una libreria per effettuare ricerche di testo su documenti, nel 
tuo caso non ne vedo l'utilità...
A titolo informativo: considerato che i dati non vengono modificati 
potresti optare per salvarli in un formato come HDF5, pensato proprio 
per archiviare grosse moli di dati. Puoi usare la libreria "Java HD5 
Interface".
Io lo uso da Python (via Pytables) e mi trovo molto bene ma ho archivi 
di diversi giga, difficile valutare in termini di record ma sono 
maggiori di almeno due ordini di grandezza.
Anche i db NoSQL sono sicuramente strumenti interessanti, ad esempio 
Cassandra è scritto in Java e ben testato con centinaia di TB.
Anche se NoSQL mostra i suoi pregi se usato in cluster e architetture 
distribuite.
Attenzione però che usando questi strumenti non hai a disposizione SQL 
(e vari wrapper, tipo ORM) ma devi lavorare direttamente sulla struttura 
dati. Cosa abbastanza banale ma comunque diversa da SQL, soprattutto 
quando si devono fare ricerche sparse e/o gestire il carico in memoria.
Se hai familiarità con i db e hai a disposizione un engine decente credo 
ti convenga usare quello.

 esistono database file-based che non richiedono un server.
Hint: SQLite, Berkeley DB
Ciao Jack

 Hint: SQLite, Berkeley DB
e Derby/JavaDB

 esistono database file-based che non richiedono un server.
Non è affatto uno shock, anche se malamente espresso, questo post mi
serve per capire come mantenere un database, senza l'onere di mettere
in piedi un server.
Percui, se hai info, son tutto orecchi!
Ciao, Davide.

 ti convenga usare quello.
Diciamo che non è un problema per me l'interfaccia da e verso Engines
SQL "Comuni", ma nemmeno imparare qualcosa di nuovo.. Percui, se ho
sostanziali benefici in termini di performance e posso mantenere
sganciata l'architettura da un Engine SQL esistente, sono contento!
Senza contare la libido di imparare qualcosa di nuovo ;)
Ciao e grazie per le dritte, Davide.

 sganciata l'architettura da un Engine SQL esistente, sono contento!
Sicuramente Cassandra è un buon investimento, come in generale tutti i 
database NoSQL, vista la sempre maggior mole di dati che si va a 
trattare anche in applicazioni relativamente banali.
Se non altro per capire i pro e contro ed essere in grado di valutare 
quale sia lo strumento migliore per le varie circostanze.
Se ti interessano le prestazioni dai un'occhiata a Redis (tra l'altro 
creato e gestito da un italiano), c'è anche la possibilità di fare dei 
test online (
try.redis-db.com
) e i wrapper Java sono discretamente 
maturi (consiglio jedis: 
https://github.com/xetorthio/jedis
).
E' un db key-value per cui l'uso "base" è intuitivo.

 e Derby/JavaDB
E HSQLDB
Enrico
P.S. no, non sto urlando :)

 piedi un server.
Cosa intendi per mantenere (ovvero, dai piu` informazioni su come vuoi 
operare e cosa devi fare con quei dati)?
Enrico

 E' un db key-value per cui l'uso "base" intuitivo.
Direi, grazie mille x i preziosi consigli, ora almeno so cosa c'è in
giro!!!
In questi giorni faccio dei test, poi vi dico...

> piedi un server.
Dati i requisiti, una tabella in sola lettura, potresti anche usare il 
Derby (ovvero JavaDB incluso nel JDK della sun) ed utilizzarlo embedded, 
che potrebbe essere anche incluso in un  jar.
-- 
Dr. Ugo Gagliardelli, Modena, Italy
Spaccamaroni andate a cagare/Spammers not welcome

http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html
nonostante il nome è un sistema di indicizzazione leggero e perfetto per la 
tua applicazione "mirata".