Newsgroup: it.comp.software.database
Titolo: Prestazioni Database

Dovendo realizzare un applicativo che salva dei dati sulla cattura di
pacchetti in rete su un database e poi grazie ad esso dare la possibilità di
ricavare un certo numero di statistiche, mi sono trovato davanti al dubbio
se era piu performante usare un'unica tabella per salvare i record oppure
usare piu tabelle differenziate magari in base al tipo di dato presente in
quel pacchetto da me catturato.
Quindi la mia domanda è:
un database lavora meglio con un'unica tabella o con più tabelle (in termini
di prestazioni, ovvero # di record inseriti al secondo) ?
Perché?
GRAZIE.

 di prestazioni, ovvero # di record inseriti al secondo) ?
Dipende da come e' implementato il database, se i dati vengono loggati
(redo) oppure no, se deve mantenere lock multipli, se scrive i dati in
memoria, se il sistema usa un raid...
A basso-basso-basso-livello si puo' dire che avendo piu' di una tabella
dovrai fare piu' di una scrittura, quindi l'I/O potrebbe essere peggiore
con tabelle multiple, ma se hai un sistema con datafile su piu' dischi con
controller separati e spartisci le tabelle in maniera intelligente le
scritture possono essere fatte in parallelo, a questo punto (per
assurdo) un sistema con piu' tabelle e' anche piu' performante perche'
sfrutta meglio l'hardware.
Davide

Ciao,
a prima vista mi sembra che il tipo di lavoro che devi fare si avvicini molto
ad un clickstream analisys; il mio consiglio è quindi di realizzare un oltp
per registrare i dati e un dwh per le analisi, alimentato mediante procedure
etl che ti permettano ad esempio di ripulire i dati o aggregarli a seconda
delle tue necessità.
Le due tipologie di basi dati sono davvero diverse tra loro.
Senza ulteriori specifiche (non hai neppure detto che db avresti in mente di
utilizzare) non si può aggiungere molto... A disposizione per chiarimenti. ;)
Saluti,
Ender

 wrote in message
news:41SC9.33535$744.1...@news1.tin.it...


 questione. [...]
Credo innanzitutto che la scelta del db sia fondamentale.
Oracle 9i è ben diverso da Access, e lo dico anche se sembra una banalità. La
scelta dovrebbe essere effettuata in base al budget che hai a disposizione e
alle prestazioni necessarie (anche in termine di sicurezza dei dati e di
disaster recovering).
Eviterei l'utilizzo di ODBC perchè è particolarmente lento, oltre ad essere
implementato male in molti casi.
Detto questo, inizierei col distinguere la parte di registrazione da quella di
analisi; creare due db è forse la cosa migliore.
Sul primo registri i dati, sul secondo scrivi delle procedure che,
rileggendoli dal primo, li rielaborano in modo che possa esserti utile.
E' difficile darti una strada precisa da seguire, ma credo che in linea di
massima alcuni esempi possano metterti sulla buona strada.
Il modo in cui registri i dati sul primo db è di tua scelta; puoi stabilire se
ci sono dei dati che possano essere definiti comuni; mi sembra di capire che i
campi MAC riguardino il mac address di una scheda di rete, e di conseguenza
possono essere comuni a molti pacchetti, cosa che ti permette di inserirli in
una prima tabella con un id univoco (es, scheda 1, mac xxx ecc.); su una
seconda, inserirai solamente i dati relativi ai pacchetti riportando anche il
codice della scheda associata (pacchetto 1, scheda 1 ecc.).
La soluzione della tabellona unica può comunque essere ottimale, specialmente
se non esistono elementi ripetitivi.
Per dirla in due parole lo metti insomma nella forma più relazionale
possibile.
Il secondo db servirà solo ed esclusivamente a chi effettua l'analisi. I dati
che ci saranno verranno inseriti da procedure, magari notturne, che si
occuperanno di caricare e rielaborare i dati presenti sul primo db.
Perchè questo sbattimento?
Perchè oltre ad una tabella con tutti i dati "grezzi", potrai generare anche
delle tabelle di sommario.
Ad esempio, una tabella che, data per data, ti dica quanti pacchetti di un
certo tipo sono passati:
11/11/2002 pacchetti_tipo_x 156
11/11/2002 pacchetti_tipo_y 1044
e velocizzare quindi i tempi di risposta nel caso in cui gli utenti finali
chiedano domande prevedibili.
Un'altra cosa che potresti fare è quella di mantenere dei sistemi olap, che
incrociando dei dati di sommario rispondano in brevi tempi a domande tipo "in
quale giorno della settimana arrivano più pacchetti di tipo x".
Questo è quello che potrebbe chiamarsi un piccolo data mart.
Anzichè eseguire query che ogni volta vanno su un numero di record molto alto
(e che è destinato a crescere col tempo) cerchi di effettuare tutti i calcoli
che possono essere fatti anticipatamente con procedure notturne, in modo che i
tuoi utenti possano poi recuperarli velocemente.
Ad un data mart puoi volendo affiancare anche dei tools di business
intelligence, quali ad esempio Business Objects o Microstrategy per realizzare
reportistica avanzata che gli utenti possano non soltanto stampare, ma con cui
possano interagire per estrapolare le informazioni di cui hanno bisogno.
Concludendo - spero di non essermi dimenticato nulla perchè l'argomento è
davvero vasto - tutto dipende da quanto è importante questa applicazione,
quanti soldi e tempo puoi investirci, quanto può rientrare all'azienda da
questo tipo di analisi.
Se reputi il progetto interessante e riesci a convincere chi di dovere che è
un investimento non avrai problemi a portarlo avanti. Considera comunque dei
costi molto alti per la sua realizzazione; se si tratta quindi di una cosa a
scopo pseudo-obbistico (ovvero "me l'hanno chiesta e sto cercando il modo di
farla senza scatenare chissà che casino") l'idea di usare Access o un altro DB
(ti consiglio Firebird al posto di mySQL comunque, ha più funzionalità e - non
posso dirlo con certezza assoluta ma solo per un impressione - maggiore
capacità di gestire grossi carichi di lavoro) e di fare un tabellone unico è
ottima.
Per quanto riguarda gli IPv6 e IPv4 io mi limiterei a inserirli in un campo
CHAR(4) oppure in un campo CHAR(16) (128 bit) come hai fatto tu. L'idea di
dividerlo in due tabelle è buona, di sicuro limiterà il carico. Puoi, nel caso
in cui tu decida di utilizzare Oracle, anche fare un partizionamento dei dati;
ovvero, decidere di suddividere la tabella in x parti e stabilire che i dati
che hanno un IP da xxx a yyy vadano in una certa partizione, quelli da yyy a
zzz in un'altra e così via. Per altri db non saprei che dirti.
Detto tutto questo, se ti servisse una consulenza effettiva fammelo sapere;
possiamo continuare la chiaccherata per email.
Mi scuso se l'esposizione non è stata buona, ma è tardino e comincio a non
connettere perfettamente. ;)
Saluti,
Ender