Newsgroup: it.comp.software.database
Titolo: [PostgreSQL8.3] [lungo] Partizionamento tabelle ogni chiusura anno

Salve a tutti,
sto valutando l'ipotesi di fare un "massiccio" partizionamento di 
tabelle per incrementare ricerche e visualizzazione e funzioni.
Premessa:
Tanto tempo fa esisteva un database. La struttura delle tabelle, di 
anche 20 colonne, era statica perchï¿œ erano queste le richieste del 
cliente e anche perchï¿œ i dati erano sempre gli stessi e con quella 
struttura. Poi nel tempo sono state aggiunte specifiche e alla fine il 
DB era irriconoscibile. Tra le specifiche piï¿œ "pesanti" vi era la 
necessitï¿œ di avere tabelle dinamiche. Per dinamiche intendo che spesso 
il record non aveva in se tutti i campi della tabella. Siccome vi ï¿œ 
differenza tra un campo null, vuoto o proprio inesistente, ho dovuto 
rimodellare il DB in maniera piï¿œ dinamica.
A oggi:
Le tabelle sono dinamiche nel senso che non vi ï¿œ un numero precisato di 
campi ma esiste una tabella che racchiude una struttura tipo(metto i 
campi rilevanti): idprogressivo, uid, idcampo, valore, data_insert. Ve 
ne ï¿œ poi un'altra che riassume in ordine di visibilitï¿œ dei campi della 
tabella. Se nel tempo la tabella dovesse variare basterebbe aggiungere o 
cancellare un record in quest'ultima tabella.
Il sistema ï¿œ testato, funziona e nel complesso piace. Ma come 
dimenticarsi di alcuni problemini? Piï¿œ che problemi sono argomenti 
attesi e studiati a priori che attendono una conferma. Nella premessa ho 
detto che prima erano presenti tabelle statiche di anche 20 colonne. Ora 
con la struttura attuale ogni record di prima si tramuta in 20 record 
attuali(piï¿œ o meno). Questo significa che se prima la tabella aveva 
20000 record ora ne ha 20000 * 20. Siccome il numero diventa notevole ho 
pensato che suddividendo per anno, piuttosto che per anno e mese o 
semestre, aumentasse la reperibilitï¿œ dei record. L'indice di questa 
tabella ï¿œ dato dall'uid asc, idcampo asc e data_insert asc. La chiave ï¿œ 
univoca sui tre campi stessi.
Domande:
- Vista la struttura attuale, come posso velocizzare la ricerca?
- La partizione della tabella ï¿œ una buona soluzione e se si come 
procedere oppure esiste di meglio?
- Tenendo presente che sul campo "valore" spesso faccio delle medie o 
delle somme raggruppando chiaramente per l'idcampo, partizionando potrei 
fare queste cose?
Grazie in anticipo per l'aiuto!!!

 
vuoi suggerimenti su come velocizzare qualcosa che non descrivi, eseguito 
su qualcosa di cui non parli (i dati cosa sono? testo? numeri? campi 
blob?), usando un metodo che non hai spigato nel post.
hum...
hem...
ritenta?
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 fare queste cose?
Certamente, lo fai con SQL pure: SUM(Eta) o AVG(Eta) senza problemi.
Ovviamente i risultati sono orizzontale, per cui farai
SELECT AVG(Eta), AVG(Altezza), AVG(Peso)

 blob?), usando un metodo che non hai spigato nel post.
Stiamo parlando di un DB di un 5% campi testo e un 95% campi numerici. 
Non integro i file che mi vengono dai sensori nel DB poichï¿œ anche se 
piccoli preferisco averli come storico sul filesystem. Percui ï¿œ 
chiaramente contemplato un campo dove inserisco il link fisico al file.
 >> Domande:
 >> - Vista la struttura attuale, come posso velocizzare la ricerca?
 >> - La partizione della tabella ï¿œ una buona soluzione e se si come
 >> procedere oppure esiste di meglio?
 >> - Tenendo presente che sul campo "valore" spesso faccio delle medie o
 >> delle somme raggruppando chiaramente per l'idcampo, partizionando
 >> potrei fare queste cose?
Grazie!

 
he...
io ho fatto un'ipotesi sulla struttura che userei, ma la tua non la conosco 
ancora.
so che hai una tabella che racchiude una 'struttura tipo', ma non credo sia 
l'unica tabella del tuo db...
non dici nemmeno se ci sono indici, chiavi o altro (c'e' un indice nel tuo 
post originale, ma e' chiave?).
partendo dal presupposto di avere gli indici a posto, imho il 
partizionamento diventa interessante se hai interrogazioni molto frequenti 
e numeri di righe veramente alti (imho 1 milione di righe non e' un numero 
alto), ma molto dipende anche dalla struttura del tuo db (che ancora resta 
un mistero...).
e se hai 500 query al secondo o 5 al minuto, le cose cambiano...
e se ognuna di queste esegue conteggi e raggruppaenti le cose cambiano 
ancora...
che ricerca vuoi velocizzare?
ricerca dei sensori?
delle letture a partire dal sensore?
delle letture di un certo periodo?
le interrogazioni/medie/calcoli come li fai?
hai stored procedures o simili oppure dai client (se ci sono dei client...) 
esegui sql creato al volo?
fatto qualche confronto tra i due metodi?
migliorare rispetto a cosa? qual'e' la situazione attuale?
se hai tempi di risposta dell'ordine del ms, mi sa che hai poco margine, se 
hai tempi dell'ordine dei minuti, magari basta aggiungere gli indici...


 tbl_valore (idsensore, idcabina, tslettura)
E non ï¿œ una struttura dinamica questa? Dove stanno le colonne fisse? Per 
ricreare una struttura di parvenza "statica" dovrei usare le crosstab.

 
adesso sono curioso di capire, perche' i sensori non sono il mio campo e
non ho proprio la piu' pallida idea dei motivi che portino alla
necessita' di cambiare la struttura delle tabelle in corso d'opera... 
;-P 
ti ribalto la domanda: quali sono le colonne 'dinamiche'?
una volta definita la struttura delle tre tabelle, quella resta e non
cambia piu'. quali sono le colonne che dovrebbero cambiare?
tanto per fare, provo a mettere giu' una struttura:
tbl_cabina (idcabina, descrizione, altitudine, longitudine, latitudine)
tbl_sensore (idsensore, idcabina, marca, modello, valmin, valmax,
unitadimisura, dataultimataratura, posizioneincabina, isattivo)
tbl_valore (idsensore, idcabina, tslettura, valore) 
con una struttura del genere, quali sono le colonne che dovresti
cambiare al volo durante il funzionamento?
se hai un valore, l'unita' di misura la leggi dalle caratteristiche del 
sensore relativo.
se hai due sensori identici tarati con range diversi, anche sulla stessa 
cabina, li puoi distinguere.
se hai N sensori identici, su M cabine, sono comunque gestibili. 
che sia chiaro: soluzione buttata li', quindi non necessariamente adatta
alla tua situazione e i sensori non sono il mio campo, quindi probabilmente 
ho tralasciato cose ovvie per chi lavora nel settore. 
in ogni caso, ancora non si sa niente del tuo db: e' un po' dura darti
qualche suggerimento, a parte 'Se hai gia' indicizzato i vari campi, non
c'e' molto che tu possa fare', come ti ha scritto andrea. 
^^


 tbl_valore (idsensore, idcabina, tslettura, valore)
Invece va benissimo... la logica ï¿œ questa. E' dinamica perchï¿œ non hai 
una tab fisica sul contenuto della cabina. Sono convinto ora che diciamo 
la medesima cosa. Per quanto mi riguarda, nel tuo esempio, un tab 
statica ï¿œ una tabella che ha un struttura simile:
[tab_risultati]
idcabina, descrizione, altitudine, longitudine, latitudine, 
temperatura_suolo, temperatura_aria, umiditï¿œ, percentuale_acq_terreno, 
quantita_acq_mm, ... [almeno 15 altre colonne sulla composizione del 
terreno e dell'aria], data_ora_analisi
Se in questa struttura dovessi aggiungere un ulteriore campo dovrei 
metterlo alla fine perdendo il senso della tabella(si potrebbe anche 
metterlo in mezzo ma rischierei forse qualcosa di piï¿œ)...
L'unico PRO che ho con una struttura statica ï¿œ che per ogni colonna 
posso definire il type del campo(numerico, testo, blob), con una 
struttura come la tua o ho tanti campi "valore"(nValore, sValore, 
bValore) definiti in modo diverso oppure sono tutti dei text e poi da 
qualche parte ho una tabella che mi definisce la tipologia di campo.
Spero di averti spiegato meglio.
PS Scusa se rispondo tardi ma non ho sempre il NG sotto mano :-|