architettura RDBMS

[andreu]

Ciao a tutti,
vorrei riprogettare l’intera rete che gestisco, e vi chiedo qualche consiglio.

La rete attualmente è composta da :
server windows 2008 locale con installata IIS e db MySQL (circa 700mb, 4-5.000.000 righe con incremento annuo di 5-600.000)
la connessione con il db avviene tramite query php su due livelli :
1- Tramite applicazioni java in dotazione al personale che scrivono e leggono sul db
2- Tramite pagina web e app android che leggono solamente dal db

Vorrei portare il db su web server, al momento ho 2 domini su register.it

Primo problema :
E’ una scelta giusta ? Credo che il web server abbia vantaggi per quanto riguarda manutenzione, sicurezza, e sia più performante come connessione.

Secondo problema
Devo basare tutto su un solo db o crearne 2 (per gli accessi esterni posso ridurre le righe a 1.000.000).
Ci sono differenze rilevanti di velocità di connessione riducendo le dimensioni del db di 4 volte ?
Per quanto riguarda la sicurezza ha senso creare un db non connesso con l’esterno che alimenta un db secondario più piccolo collegato con i client, web e app (magari usando 2 domini distinti) ?

Grazie.

[optime]

primo problema: il web server ha senso solo se devi dare la possibilità di accedere dall'esterno
secondo problema: ridurre il numero di record potrebbe (potrebbe!) ridurre i tempi di accesso, ma poi ti trovi ad avere a che fare con i problemi di sincronizzazione. Forse vale la pena di studiare bene le modalità di accesso

ma devi darci delle info in più

[andreu]

Grazie per l'interesse.

provo a essere più chiaro :

Il logic tier è composto al momento da pagine php, alle quali accedono le connessioni dall'esterno, che si possono dividere su 2 livelli :

1- connessione da parte di applicazioni java in numero limitato e gestite da collaboratori, scrivono dati sul db, non presentano particolari problemi di sicurezza.

2- accesso degli utenti dal sito o tramite app android, leggono i dati. Per questo livello non è necessario vedere tutto il db, bastano ultimi 2 anni (max 1.000.000 di righe)

Ipotesi 1 - unico db sul quale il livello 1 scrive e il livello 2 legge.
Mi pare di aver capito leggendo in giro che la velocità di risposta non aumenta sensibilmente al variare delle dimensioni, mi preoccupano di più la sicurezza, eventuali conflitti se i 2 livelli scrivono e leggono dallo stesso record.

Ipotesi 2 - 2 db su 2 domini distinti, uno principale (connesso al livello 1 solamente), che alimenta il secondo db con accesso da parte del secondo livello. Non so se vale la pena di complicarsi la vita, considerando come dici tu i problemi di sincronizzazione.

Ipotesi 3 - potrei tenere il db principale (connesso al livello 1 solamente) in locale sul server win2008 (struttura già esistente) e creare un web server solo per il db con accesso da parte del secondo livello.

Grazie.

[optime]

per quanto riguarda gli accessi contemporanei, è un problema che devi gestire sempre e comunque, indipendentemente dagli approcci per la pubblicazione del dato.
per quanto riguarda i due db, l'unica cosa che può spingerti a farlo è la sicurezza (interno per lettura e scrittura, esterno solo lettura)

[andreu]

E se il secondo db (quello esterno di sola lettura) lo configurassi non relazionale ?
aumenterebbero i problemi di sincronizzazione ma, presumo aumenterebbero sensibilmente anche le prestazioni (tra 1 query con 20 join e una semplice) ?
Ha senso come ipotesi o mi sto complicando la vita ?

Grazie.

[optime]

che vuol dire farlo non relazionale? ma stai messo così male con le prestazioni?

[andreu]

Bè, per quanto riguarda le prestazioni, al momento il web server è ospitato su un server locale e non è un razzo, ma immagino che virtualizzandolo migliorerà parecchio, più che altro vorrei capire tutte le variabili per decidere la soluzione migliore.
Ho visto da qualche parte un grafico che mostrava come la velocita di risposta del db non variasse in base alle dimensioni ma al numero di query.
Consideravo quindi il mio db nel quale la tabella principale (quella che l'utente interroga) contiene 20 colonne che riportano l'ID di altrettante tabelle. Per estrarre una riga "leggibile" devo sostituire ai 20 id, i valori riportati nelle relative tabelle con dei join

$queryLista= "SELECT *
FROM tabellaPrincipale
LEFT JOIN
  tabella1
  ON tabella1.id = tabellaPrincipale.nome
...
WHERE nome='$comboNome' AND cognome='$comboCognome' ";

credo di aver capito che leggere tutte le tabelle e risolvere i join nella pagina php sia più lento.
Ma, nel caso crei un secondo db (esterno di sola lettura), se ci mettessi solo la tabella principale con i join già risolti in fase di sincronizzazione, la query sarebbe più semplice

$queryLista= "SELECT *
FROM tabellaPrincipale
WHERE nome='$comboNome' AND cognome='$comboCognome' ";

Ha senso considerando l'aumento di sicurezza e di prestazioni valutare questa ipotesi ?

[optime]

per le prestazioni devi considerare l'uso di indici sulle colonne interessate dalle join, e non fare select * ma select colonne_necessarie

valuta anche l'uso di stored procedures e tabelle temporanee

in sql server farei così

SELECT colonne
INTO #tmp
FROM tabellaPrincipale
WHERE nome=@comboNome AND cognome=@comboCognome

SELECT t0.colonne, t1.colonne
FROM #tmp T0 JOIN tabella T1 on t1.id = t0.nome



o anche



SELECT colonne
FROM tabellaPrincipale
LEFT JOIN
tabella1
ON tabella1.id = tabellaPrincipale.nome
AND nome='$comboNome' AND cognome='$comboCognome'

(cioè la where direttamente nella join)

[andreu]

Molte grazie, consiglio utilissimo. Scusa però se insisto , vorrei togliermi dalla testa il dubbio.
Ritieni che le prestazioni tra una query con join (anche ottimizzata come la tua) e una diretta (su un db già tradotto) siano tali da rendere ipotizzabile la fatica di creare 2 db o sia tempo perso ?

Ancora grazie per l'aiuto.

[optime]

il tuo sarebbe un processo di denormalizzazione (http://it.wikipedia.org/wiki/Denormalizzazione) e potresti avere dei vantaggi. Fatti due prove e vedi