[Linuxtrent] Re: consiglio su db
- From: Emanuele Olivetti <olivetti@xxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Thu, 17 Oct 2002 16:37:50 +0200
On Thu, Oct 17, 2002 at 04:23:08PM +0200, Luca Manini wrote:
> >>>>> "Emanuele" == Emanuele Olivetti <olivetti@xxxxxx> writes:
>
> Premetto la mia gnuranza in fatto di DB, ma siccome ti hanno
> risposto proprio tutti, mi lancio anch'io in un paio di
> osservazioni.
Postmetto ma mia gnuranza e cerco di rispondere.
>
> Emanuele> Sto valutando la possibilita' di utilizzare un db per
> Emanuele> gestire i dati per un' applicazione di analisi dati da
> Emanuele> fare in c++ su linux e non so orientarmi.
>
> Analisi dati mi pare un po' generico, no? (sarà che ho appena
> letto un documento su come fare le domande affinché i guru
> ti rispondano qualcosa di diverso da RTFM).
>
> Con analisi intendi che i dati ci sono già, quindi tutto il lavoro
> è a bocce ferme (grandi analisi su un DB vivo sono un gran
> casino)?
>
> Se sì mi viene da dire che di transazioni e atomicità forse non
> sai cosa fartene (credo) e che la struttura sarà più di quella di
> un DB di data-warehousing (poca roba relazionale, grande
> ridondanza, tonnellate di indici precalcolati) che di OLAP (evvai
> di buzzword).
>
> Insomma, dicci qualcosa di più.
>
Prendi delle tabelle di numeri, fai una prima selezione facendo qualche
conto su ogni record e ottieni un sottoinsieme dei record; fai altri
conti e riduci l'insieme ecc. per un po' di volte. Poi sul risultato
finale fai girare la parte piu' pesante dei conti (farlo su tutti i dati
richiede 10^n anni macchina).
Le richieste sono che si vuole tenere traccia dei risultati intermedi
di OGNI passaggio (ogni "selezione") oltre che del risultato. Inoltre
deve essere possibile tracciare le operazioni fatte per raggiungere
un determinato risultato intermedio per poter tornare indietro a
ricontrollare o semplicemente "guardare".
Tutto qui per ora. Quando avro' le idee piu' chiare vi faro' sapere.
> Emanuele> I vincoli sono:
>
> Emanuele> 1) bisogna cercare la massima efficienza (performance)
> Emanuele> perche' precedentemente il tutto veniva gestito tenendo
> Emanuele> i dati su file ed era una scheggia. Ovviamente la
> Emanuele> velocita' dipende anche da cosa voglio fare dei dati e
> Emanuele> come li strutturo, ma questo e' un altro discorso.
>
> A parte stare su file, è necessario poter usare SQL o no? Se sì,
> mettere tutto in un DB è un buon sistema di avere l'SQL, ma forse
> è il caso di vedere se l'SQL di turno ha le funzioni di (supporto
> per) analisi che ti servono (dovercele aggiungere non è proprio
> una libidine).
Il Db servirebbe solo per un mero fatto organizzativo, per non dover
creare migliaia di file con nomi improponibili. L'SQL puo' essere
comodo per fare qualche estrazione con poca fatica...
Le vere analisi si fanno con del codice a parte sul risultato delle
query.
>
> Emanuele> 2) i record potrebbero essere dell'ordine di 500.000 -
> Emanuele> 1.000.000
>
> Magari se ci dici anche quante sono le tabelle, o meglio ci dai
> una idea di tabelle -> numero-di-record...
>
Alla struttura giusta devo ancora pensare, per ora si puo' pensare un
unico tabellone uniforme per i dati e a non so cosa per tracciare
i risultati intermedi (tenuti in tabelle analoghe ai dati iniziali).
I risultati intermedi sono da tenere da parte sempre, anche se l'analisi
sembra finita. Se si interrompe un'analisi per qualche motivo sarebbe
bello poterla riprendere dopo semplicemente "continuando" (insomma
lo stato deve essere salvato...)
> Emanuele> 3) il record e' composto da meno di una decina
> Emanuele> di campi quasi tutti numerici (int, float ecc.) e magari
> Emanuele> un paio di brevi stringhe (< 10 caratteri).
>
> Come IL record, non erano tanti :-)
>
> La matematica non è il mio forte, ma 1M * (10 * 4 + 2 * 10) ci sta
> tutto in memoria, anche pensando ad un overhead del 100% di indici
> (o parenti). A meno che le tabelle da 1M record non siano tante...
Potrebbe non essere possibile in futuro (ora si).
>
> Emanuele> 4) vorrei un db "libero" (quindi non consigliatemi
> Emanuele> oracle)
>
> Lungi da me
>
e da tutti noi! ;-)
> Emanuele> 5) deve interfacciarsi bene con il c++ (questo penso sia
> Emanuele> il problema minore)
>
> Nel senso che quasi tutti si interfacciano con il c++? Può
> darsi. Che poi "usare" il c++ sia un problema
> minore...degustibus.
>
Sembra che tutti si interfaccino facilmente con il c++. Il C++ e' scelto
per cercare l'efficienza. In realta' non da me. Ma condivido la scelta visto
l'obiettivo.
Ciao!
Emanuele
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con SOGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
Other related posts: