Database grosso e performance

[IlMerovingio]

Sto lavorando ad un progetto, sviluppato in php/mysql con diversi database di dimensioni variabili tra i 15k e i 180k records (nel mio caso ad ogni 1k records corrisponde circa 1mb di spazio su disco e la somma di tutti i records presenti nel database è circa 320k purtroppo in costante aumento).

La mia domanda è: a livello di performance fare delle grandi SELECT UNION non è molto più lento che fare più SELECT "normali"? Chiedo perchè da quando ho iniziato ad interfacciare il sistema su più database mi sembra di avere un calo di performance.

Sotto il punto di vista della manutenzione preferisco avere db divisi ma per il coding viene tutto più complicato.

Visto che questo script dovrebbe lavorare in costante stress e non ho intenzione di prendere chissà quale bomba di dedicato, pensate mi convenga fare delle SELECT su un unico db di 320k o delle UNION SELECT su database diversi (che però come somma fanno sempre 320k? )

Tnx

[FlameNetworks]

Molto dipende da questi fattori:

- struttura delle tabelle
- tipologia di campi
- engine

Prendi una macchina con un buon quantitativo di RAM, così da avere tutto il DB in memoria.

Ciao,

F.

[ToX]

la butto li senza avere alcuna idea di cosa sto dicendo, ma visto che ultimamente sembra che in molti facciano questo passaggio, usare un database non relazionale non è un'opzione?

The Apache Cassandra Project

[Uno]

pensate mi convenga fare delle SELECT su un unico db di 320k o delle UNION SELECT su database diversi (che però come somma fanno sempre 320k? )

Tnx

Se non è possibile cambiare la logica dell'applicazione, senza neanche sapere cosa devi fare realmente, da quello che dici parrebbe meglio un unico db (o intendi tabella? Comunque è lo stesso)

[IlMerovingio]

Molto dipende da questi fattori:

- struttura delle tabelle
- tipologia di campi
- engine

Prendi una macchina con un buon quantitativo di RAM, così da avere tutto il DB in memoria.

Ciao,

F.

Le tabelle son tutte uguali come struttura, 4 campi INT, 1 DATE, 6 TEXT. Come engine vorrei utilizzare MySql.
Ho valutato di mettere tutto il db in RAM e di farne una copy ogni tot minuti sul db ma volevo sapere appunto se anche utilizzando db in ram è conveniente fare SELECT UNION o la somma di più SELECT.

la butto li senza avere alcuna idea di cosa sto dicendo, ma visto che ultimamente sembra che in molti facciano questo passaggio, usare un database non relazionale non è un'opzione?

Ti ringrazio per l'idea, in effetti ci avevo già pensato è che ho poco tempo per effettuare le modifiche e fare un cambiamento così radicale un po' mi spaventa

Se non è possibile cambiare la logica dell'applicazione, senza neanche sapere cosa devi fare realmente, da quello che dici parrebbe meglio un unico db (o intendi tabella? Comunque è lo stesso

Non ho detto che non è possibile cambiare la logica dell'applicazione, è che effettuare una SELECT UNION comporta cambiare solo un po' di query nello script. Usando invece la somma delle SELECT invece bisogna proprio metter mano alla struttura dello script (volevo solo capire se il gioco vale la candela a livello prestazionale ). Non vorrei infatti magari lavorare e modificare tutta l'applicazione per aver poi lo stesso risultato prestazionale.

Cmq si "uno", ho fatto confusione intendevo tabella non database.

[Uno]

Le tabelle son tutte uguali come struttura, 4 campi INT, 1 DATE, 6 TEXT.

Si ok, ma indicizzate come?
E come le metti in relazione tra loro?

[2busy]

Come engine vorrei utilizzare MySql.
Ho valutato di mettere tutto il db in RAM.

Putroppo non dici granchè

Si ok, ma indicizzate come?
E come le metti in relazione tra loro?

Per le union credo basti semplicemente che le tabelle abbiano lo stesso numero di campi e che questi siano dello stesso tipo o comunque convertibili.
L'integrità referenziale non dovrebbe essere richiesta.

edit: anche perchè non avrebbe troppo senso mettere in relazione tabelle che contengono gli stessi campi...
Le union non sono join, servono a unire risultati di query fatte su diverse tabelle che sono state a loro volta spezzettate per comodità o altri motivi ma che contengono gli stessi campi.

[guest]

Ho letto solo 1 cosa: TEXT. I text non vanno mai in memoria, quindi puoi fare quel che vuoi, compreso mettere 32GB di ram, ma non userai mai un singolo bit di cache.
Se tutte le tabelle hanno cache, acquista dischi SAS da 15K RPM piuttosto che grosse quantità di ram. Il collo di bottiglia saranno i dischi nel tuo caso.

Inoltre, tutte le volte accedi a tutte le tabelle? In tal caso, forse fare una singola tabella è conveniente, come dice Uno.
Se, invece, a volte accedi a tabelle differenti, separare le tabelle avrebbe un senso, perchè mysql caricherebbe in ram solo quelle usate.

Ma prima devi risolvere il problema dei campi TEXT.
Se ti servono meno di 255 caratteri usa VARCHAR. Se ti serve veramente un TEXT, valuta l'utilizzo di una tabella dedicata con i soli TEXT.
Fai le query su tutto il resto delle tabelle, poi alla fine, leggi i singoli valori dalla tabella TEXT mettendo un indice sugli ID.

Ma non sapendo cosa deve fare lo script, si fa fatica ad aiutarti. Devi fare delle ricerche full-text sopra i campi TEXT?

[Uno]

Putroppo non dici granchè


Per le union credo basti semplicemente che le tabelle abbiano lo stesso numero di campi e che questi siano dello stesso tipo o comunque convertibili.
L'integrità referenziale non dovrebbe essere richiesta.

edit: anche perchè non avrebbe troppo senso mettere in relazione tabelle che contengono gli stessi campi...
Le union non sono join, servono a unire risultati di query fatte su diverse tabelle che sono state a loro volta spezzettate per comodità o altri motivi ma che contengono gli stessi campi.

Non c'è solo la relazione campo tabella A -> campo tabella B
C'è anche la relazione tra tabelle e applicazione e poi di conseguenza tra tabelle.
Senza aver almeno un accenno sulla logica dell'applicazione non si può andare oltre a ciò che è stato già detto.

[IlMerovingio]

In maniera spicciola, ho una tabella per ogni istituto scolastico di una città contenente alcuni dati degli studenti iscritti (numero di matricola, nome, età etc....)

Come già detto in precedenza le strutture sono sempre le stesse per tutte le tabelle (uso spesso TEXT al posto di VARCHAR per il limite dei 255 caratteri anche se sto valutando di metterli come consigliato in una tabella separata [domanda da uno poco esperto: perchè non traggo beneficio se uso TEXT mettendo il db in ram?])

Ora sto elaborando l'applicazione front-end che permette quindi di visualizzare i risultati e mi servo di query strutturate su questo genere...

(SELECT * FROM $nometabella1) UNION (SELECT * FROM $nometabella2).......

Dal punto di vista della stesura del codice mi viene ovviamente più semplice usare un unica tabella con tutti i record di tutti gli studenti ed aggiungere alla struttura un campo "nomescuola" per risalire dove effettivamente siano iscritti.

Dal punto di vista della manutenzione del db preferisco però usare tabelle distinte e fare delle UNION.

Dal punto di vista prestazionale, qual'è la soluzione migliore? Spero di avervi dato tutte le informazioni possibili per spiegare la situazione

Grazie ancora a tutti

[Uno]

Ecco...
Non volevo fare il saccente prima di sapere cosa effettivamente devi fare, ma volevo già dire che c'era qualcosa di strano. Adesso posso dire che stai sbagliando la progettazione.

Tabella istituti
ID
Nome istituto

Tabella alunni
ID
Nome Alunno
ID istituto

Tabella profili
ID Utente
dati vari


Questo ovviamente presupponendo che il singolo studente frequenta un solo istituto, altrimenti occorrerebbe un'altra tabella per velocizzare il tutto.

[ceccus]

Salve,
Allora, i campi di tipo Text, solitamente, sono "non indexable" ... e mi pare di aver detto tutto ...
In più, mettendoli a sè stante, il motore del DB è in grado di eseguire delle ottimizzazioni a livello di Storage ... in più, anche le colonne Varchar dovrebbero essere le ultime della Tabella, per lo stesso motivo esposto precedentemente.
Anche se o DB sono in memoria, occorre, a mio avviso, effettuare questi ragionamenti, perchè portano effettivamente dei vantaggi ...

Ciao !!

[IlMerovingio]

Ecco...
Non volevo fare il saccente prima di sapere cosa effettivamente devi fare, ma volevo già dire che c'era qualcosa di strano. Adesso posso dire che stai sbagliando la progettazione.

Tabella istituti
ID
Nome istituto

Tabella alunni
ID
Nome Alunno
ID istituto

Tabella profili
ID Utente
dati vari


Questo ovviamente presupponendo che il singolo studente frequenta un solo istituto, altrimenti occorrerebbe un'altra tabella per velocizzare il tutto.

Non voglio neanche io fare il saccente ma non è la prima volta che lavoro con php/mysql e so che il db è abbastanza contorto e la soluzione migliore è quella che mi hai descritto

Il problema è che i database a me arrivano così strutturati e non li posso manipolare (oddio posso manipolarli ma poi per la manutenzione che devono farci [altri ] dovrei ridarglieli con la struttura con cui mi son stati consegnati).

E' per questo che vi chiedo una soluzione a riguardo, è la prima volta che mi capita di lavorare con un db così importante e così mal pensato.

@ceccus: grazie della precisazione

[guest]

Come già detto in precedenza le strutture sono sempre le stesse per tutte le tabelle (uso spesso TEXT al posto di VARCHAR per il limite dei 255 caratteri anche se sto valutando di metterli come consigliato in una tabella separata [domanda da uno poco esperto: perchè non traggo beneficio se uso TEXT mettendo il db in ram?])

Per il semplice motivo che i dati di tipo TEXT o BLOB non possono andare in ram.
Lo storage Memory di MySQL non supporta dati TEXT o BLOB, pertanto non puoi cachare tabelle contenenti tali tipologie di dato.

Quindi in un database in ram (storage = MEMORY) non potrai creare colonne di tipo BLOB o TEXT.

[Uno]

Il problema è che i database a me arrivano così strutturati e non li posso manipolare (oddio posso manipolarli ma poi per la manutenzione che devono farci [altri ] dovrei ridarglieli con la struttura con cui mi son stati consegnati).

Se non li puoi manipolare non puoi neanche dividere le tabelle in tabelle più piccole.... (che comunque non risolverebbe nulla).
Quindi l'unica cosa che potresti fare è dirgli di usare più risorse hardware

Altrimenti dai una risistemata al tutto.