Ho due possibilità per un database:
- 33 tabelle, di cui una con 107254 righe (+350/400 al giorno)
- 3000 tabelle (+20 al giorno circa) ma con dimensioni limitate
la frequenza di SELECT sulle 3000 tabelle o sulla megatabella è molto alta (100 al secondo circa) e va in crescendo anch'essa.
Alcuni hanno già detto che è meglio il primo caso.
Qualcuno può dire la sua?
Cerco di raccogliere un po' di pareri prima di agire.
Grazie a tutti in anticipo.
nessuno?
sai dipende anche dal tipo di select.
dipende da quanti campi, quanto grossi, quanto aggiornati, quanto sono in ordine.
insomma un conto è fare 1000 select su una tabella con un autoincrement o una chiave unica, un altro è fare su un campo testuale magari un blob.
di + non so dirti, mi spiace
i campi sono poco aggiornati e poco cancellati ma ci sono spessissimo aggiunte (+350/400 al giorno come ho detto).
le select estraggono per lo più tutti i campi di 1-20 righe al massimo.
i campi sono 18, molti sono INT, alcuni VARCHAR e un campo LONG TEXT.
La chiave univoca è data da due campi interi.
è una mia mania, + che 1suggerimento:Originariamente inviato da angykiss
i campi sono poco aggiornati e poco cancellati ma ci sono spessissimo aggiunte (+350/400 al giorno come ho detto).
le select estraggono per lo più tutti i campi di 1-20 righe al massimo.
i campi sono 18, molti sono INT, alcuni VARCHAR e un campo LONG TEXT.
La chiave univoca è data da due campi interi.
agli int sostituisci gli smallint o addirittura i tinyint.
così le tabelle sono più leggere, soprattutto se sono belle grosse.
cmq io opterei per più il sistema a + tabelle:
1) in caso di rotture, malfunzionamenti, query che non vanno, sai dove agire e non devi rimettere in piedi enormi quantità di dati.
fidati è meglio avere tante piccole che una gigante!
2) puoi individuare quelle + "sfruttate" ed ottimizzarle/monitorarle/ripararle meglio.
3) se non sbaglio, in termini di memoria sono meglio quelle piccole che quelle grosse, perchè cmq con 1 select credo le legga tutte (o quasi) e poi estragga quelle che servono.
suggerimenti:
* leggi le discussioni sulle "limit" nelle query ed il tipo di memoria utilizzata
* manda pvt ai guru tipo gm, daniele_dll e chiedi se ti rispondono a questa discussione. sono sempre stati molto gentili con me.
Intanto che tipo di tabelle usi? (MyIsam o InnoDB?)
Oltre alle SELECT conta molto anche la frequenza degli UPDATE.
Utilizzando MyIsam (un suicidio secondo me) la prima ipotesi mi pare decisamente più svantaggiosa, ogni UPDATE o INSERT blocca l'intera tabella, quindi un dramma a quei livelli di carico.
Con InnoDB le cose cambiano, perché tutte le SELECT non bloccanti (quindi niente LOCK IN SHARE MODE e niente FOR UPDATE) possono essere effettuate anche in contemporanea agli UPDATE, quindi in questo specifico senso suppongo (ma attendo comunque smentita dai meglio informati) che a livello di prestazioni le due ipotesi da te fatte si equivalgano o ci siano poche differenze.
Devi comunque tener presente l'overhead aggiuntivo necessario per gestire la seconda situazione (quella con 3000 tabelle in aumento), perché frammentare i dati necessita poi di logica aggiuntiva per "vederli" come un tuttuno a livello superiore.
Riassumendo quindi (e scusa per la logorrea) io in attesa di notizie più certe circa le prestazioni delle due ipotesi, farei la prima.
ha perfettamente ragione.Originariamente inviato da skidx
[...]
Devi comunque tener presente l'overhead aggiuntivo necessario per gestire la seconda situazione (quella con 3000 tabelle in aumento), perché frammentare i dati necessita poi di logica aggiuntiva per "vederli" come un tuttuno a livello superiore.
[..]
credo di aver sbagliato.
ovvero il mio discorso "tiene" se ci sono poche tabelle.
pensavo che 3000 fosse un numero "sparato" per esagerazione.
Come sei arrivata a questi due bivi? Hai proceduto con una progettazione formale, cioè, con schema ER e vari raffinamenti? o sei andata a ruota libera?
Il mio prof quando ci faceva fare i carichi di lavori sui db ci faceva contare una lettura vale 1 e le scritture (più pesanti) 2.
Imamgino che se dividi in 3000 tabelle un inserimento comportera la scrittura su molte tabelle, fai un calcolo approssimativo e vedi cosa conviene.
poco chiaro...hai ragione!
Ps. se vuoi posso cercarti le slide del corso DBI.
a me ! a me!!Originariamente inviato da Admin5
Ps. se vuoi posso cercarti le slide del corso DBI.
a me servonooooo ooooooooo oooooooo ooooooo ooooooo ooooooo oooooo ooooo o!!!
http://alpha.dmi.unict.it/lezioni2002
questo dovrebbe essere l'url, ma il server è down, come ogni buona facolta di informatica ha i server che fanno skifo
Permessi di invio
Rispondi quotando