www.vincenzomanzoni.com

[Giorgio]

Ho una domanda da porre ad ingegneri informatici e non.

Ho una tabella di un database che possiede più di 4 milioni di record e per accedervi velocemente ho creato una serie di indici: funziona perfettamente.

Ora però ho un problema. Lo spazio occupato è troppo grande, perciò volevo sapere se conoscevate una maniera alternativa per poter accedere ai dati, ad esempio utilizzando un file binario o qualcosa del genere...

Ogni record della tabella possiede molti campi (circa una ventina), potrei eliminarne molti, ma lo spazio occupato rimane troppo grande. Mi serve una soluzione differente, che mi permette di avere uno spazio di memoria occupata molto più basso ed allo stesso tempo un accesso veloce ai dati.

Qualche idea?
_________________
Nessuno potrà viver la mia vita al posto mio, per quanto mi identifichi nel battito di un altro, sarà sempre attraverso questo cuore... - Jovanotti, "Mezzogiorno"

-- My site

[vinz]

[Giorgio]

[Pastacolpesto]

900 Mega per 4 milioni di record? Ma sei sicuro?
Che db è?

Comunque se non ti servono tutte le informazioni ti consiglio di farti un'altra tabella con sole le informazioni che ti servono, sicuramente la cosa è più veloce.
Che tipo di query dovresti fare?

Io non l'ho mai usato, ma se è SQl server c'è un tool che mentre fai un po' di query cerca di trovare una fantomatica esecuzione ottima della query piazzando indici qua e là. L'hai provato?
_________________
La teoria è quando si sa tutto e niente funziona. La pratica è quando tutto funziona e nessuno sa il perché. Noi abbiamo messo insieme la teoria e la pratica: non c'è niente che funzioni... e nessuno sa il perché..
A.Einstein

[Tomaux]

Imparati le informazioni a memoria!
_________________
A volte mi fermo e penso:
"THE EARTHQUAKE!!! OH MY FUCKING GOD, THE EARTHQUAKE!!!"

[Francesco]

A mio parere, e per quello che ho studiato di db, il fattore occupazione su disco vs. velocità di accesso è un trade off, ovvero aumenti la velocità aumentando gli indici e quindi lo spazio occupato e viceversa, non è che puoi scappare tanto lontano da questo...
Non vorrei dire stupidate, ma mi sembra di ricordare che il para o qualche esercitatore all'epoca ci avesse detto che i db più veloci e speed-critical usano anche il 90% dello spazio occupato solo per gli indici!

Come consiglio ti direi di ridurre all'osso i campi, tanto per iniziare, quindi cercare se esiste qualcosa che ti permetta di comprimere in maniera trasparente all'utilizzatore i dati del db, inoltre controllare se esistono dati ridondanti e se ad esempio una diversa struttura potrebbe migliorare le cose. Se hai query statiche e predefinite anche un'ottimizzazione delle query potrebbe essere una via percorribile.
Infine dopo che hai rimpicciolito il tutto, ti metti a smanettare con gli indici fino a quando raggiungi la dimensione limite che vuoi avere. Così a naso ti direi che probabilmente puoi indicizzare in modo "custom" sulle tue query, sempre che siano statiche ovviamente, ovvero individuare qual'è l'operazione più dispendiosa che esegue la tua query e cercare di lavorare su quell'aspetto, quest'ultima cosa me la sono appena inventata, non sono affatto sicuro che sia una strada percorribile nella pratica!
_________________
God is real........... unless declared integer or long

[Giorgio]

Allora, come già avevo detto la riduzione dei campi non è un problema, non tutte le informazioni presenti sono necessariamente utili.

Grazie per i vostri consigli, ma a me interessa avere una soluzione alternativa all'utilizzo di un DB... Se esiste. Cioè un file con un formato particolare o qualcosa di simile, dove posso scrivere gli stessi dati presenti nel DB (anzi molti meno).
_________________
Nessuno potrà viver la mia vita al posto mio, per quanto mi identifichi nel battito di un altro, sarà sempre attraverso questo cuore... - Jovanotti, "Mezzogiorno"

-- My site

[Francesco]

XML? CSV? Però l'accesso a questi file è sequenziale, quindi dovresti scorrere sempre tutto e con milioni di record.... ci metti anni... non so, magari esistono metodi di accesso alternativi, magari no...
_________________
God is real........... unless declared integer or long

[Giorgio]

[abaddon]

4milioni di righe su file è da suicidio che sia xml o meno o_o
francamente non ho ben capito il problema all'inizio pensavo che volevi ottimizzare il db, ora parli di metodi alternativi per memorizzare le cose...

a sto punto se effettivamente è così il consiglio di Fede non è male, nel senso, selezioni le cose che ti interessano e ti ricrei un db customizzato con i dati che ti interessano e quello grosso lo "butti".

Potresti guardare anche i tipi di dato da utilizzare, infatti a seconda del tipo di dato che hai cambia la dimensione es:

char=1 byte int=4 byte; long=4 byte (prese al volo da un sito, spero siano giusti perchè francamente non mi ricordavo più )

comunque il discorso è che se usi un campo char per scrivere 10000 hai usato 5byte se usavi un int ne usavi 4byte e lo stesso il contrario, se hai numeri piccoli allora forse ti conviene salvarli come char così usi 1 byte invece di 4 byte costanti... perdendo ovviamente gli operatori anche se volendo potresti usare alcuni comandi tipo CAST o CONVERT per castare i dati al volo a livello di query (in SQLSERVER ci sono sti comandi perchè li ho usati recentemente, penso anche negli altri DB medio alti)

boh queste sono le cose che mi vengono in mente, poi ci sarebbe da leggere qualche enciclopedia sulla gestione dei dati presumo...

[Andrea]

XML è da spararsi...

[vinz]

Giorgio, secondo me dovresti specificare meglio i requisiti. Puoi usare o no un database? Perché se sì, la soluzione migliore è quella di fare una analisi delle tabelle attuali, fare una proiezione sugli attributi che ti sevono, costruirci sopra degli indic furbi (hash o BTree a seconda) e poi usare SQL per le query.
Difficilmente puoi, con moderato sforzo, fare meglio di un db in termini di velocità.

Se invece non puoi usare un db, devi per forza usare un file binario. A questo punto ti devi creare due file: uno che contiene i dati e uno che contiene gli indici ai dati. All'avvio, carichi in memoria solo il contenuto dell'indice, sull'indice fai le interrogazioni e quindi accedi al file con le informazioni.

Personalmente, non vedo altre alternative.
_________________
Let the future tell the truth and evaluate each one according to his work and accomplishments. The present is theirs; the future, for which I really worked, is mine.
Nikola Tesla

[Giorgio]

[vinz]

Dato che 900 MB non sono poi "moltissimi" , potresti pensare di caricarli prima in memoria e poi accederci direttamente. In questo caso, devi crearti tu una struttura che li contenga, allocare lo spazio in memoria in maniera dinamica (malloc o new) e poi crearti una struttura ad indice (magari ti basta solo un hash) per andare a "prenderli".
_________________
Let the future tell the truth and evaluate each one according to his work and accomplishments. The present is theirs; the future, for which I really worked, is mine.
Nikola Tesla

[Giorgio]