Newsgroup: it.comp.software.database
Titolo: Performance: database multipli o partizionamento?

Posto anche di qua la richiesta fatta su ficd.mysql
 
Supponendo di dover gestire un database dove alcune tabelle contengono
decine di milioni di record, per non avere un collo di bottiglia in
caso di select ed insert in tali tabelle, sarebbe opportuno
partizionare i dati oppure creare database multipli divisi per utente?
 
Nel primo caso, avrei un singolo database dove lo user_id sarà la
chiave di partizionamento.
Nel secondo caso, clonerei la struttura (relativamente semplice e
piuttosto stabile) e modificherei il codice per collegarsi ad un
database piuttosto che un altro.
 
Il secondo è sicuramente più scalabile anche in futuro, se un singolo
server non dovesse bastare, posso spostare as-is alcuni database e
cambiare l'host di connessione a livello di PHP.
Nel caso di un partizionamento, se la singola macchina non dovesse
bastare poi son dolori.
 
Sarei propenso per creare database multipli, voi che dite? Mi sembra
la soluzione più rapida, più semplice e più scalabile.
 
L'unico lato negativo che vedo sono le variazioni alle strutture delle
tabelle, ma nella remota possibilità che ciò si renda necessario,
basterebbe scriptare le alter table.
 
-- 
Tu non puoi passare!
Sono un servitore del fuoco segreto e reggo la fiamma di Anor!
Il fuoco oscuro non ti servirà a nulla, fiamma di Udur!
Ritorna nell'ombra! TU NON PUOI PASSARE!

 partizionare i dati oppure creare database multipli divisi per utente?
 
Non sono un guru dei database ma secondo me la risposta e': nessuna 
delle due.
 
Ho avuto a che fare con un db postgres e tabelle di qualche milione di 
record, lavorando di indici e ottimizzazioni il tempo delle query era 
accettabile (e parlo di hardware di piu' di  5 anni fa, non nato per 
fare quello).
 
Dividere i db non lo farei neppure sotto tortura...
 
Comunque, secondo me, ci sono troppe variabili ignote a partire dal tipo 
di db server da utilizzare e dal tipo di query che ci dovranno girare sopra.
 
Eventualmente valuterei servizi specifici tipo RDS di amazon.
 
Ciao.
 
-- 
Pubblicita' regresso: 
http://www.ferrero.org
 
** Per scrivermi in mail, sostituire nutella con ferrero...
** To contact me by email, change nutella to ferrero...

 Eventualmente valuterei servizi specifici tipo RDS di amazon.
 
L'esternalizzazione dei dati è esclusa.


 restante 10% sono SELECT su chiave primaria.
 
Se questo e` il tuo scenario, hai valutato DB NoSQL come MongoDB e 
CouchDB? O addirittura key-value stores come MemcacheDB, Cassandra, ecc.?
 
Bye.

 CouchDB? O addirittura key-value stores come MemcacheDB, Cassandra, ecc.?
 
Si. Significa rifare tutto, ma proprio tutto
 
adesso sto testando la connessione a più db. Ho risolto, per ora, con 
una riga dentro un IF
 
$db_prefix = '';
if ( class_exists('Registry')
      && !in_array($name, array('config', 'user', 'visitor')) ) {
 
          $db_prefix = $user.'.';
}
 
$table_name = $db_prefix.$table_name;
 
 
Ma rispetto al partizionamento nativo di MySQL, ci son differenze
prestazionali ? ad esempio, se partizionassi le tabelle in 15 parti,
suddivide per user_id, avrei lo stesso risultato rispetto a 15 database?
(intendo come performance)


 (intendo come performance)
 
Ma stai parlando di un singolo server o di server multipli?
Dal codice che posti sembra che tu abbia un singolo server.
 
In questo caso, se fai tutte le query su chiave primaria, secondo me ti 
stai complicando la vita. Se hai abbastanza RAM da tenerci gli indici, 
secondo me conviene tenere una singola tabella.
 
Ma lascio la parola a chi ha avuto a che fare con tali moli di dati.
 
Bye.

 secondo me conviene tenere una singola tabella.
 
Il concetto che sapevo io e' che, generalmente, nessun trucco 
funzionera' meglio di quello che puo' gia' fare il db, che nasce per 
questi compiti. Eventualmente si lavora di ottimizzazioni.


 questa esigenza di avere decine di milioni di record?
 
Se si tratta dello stesso progetto di cui l'OP parlava su icol.sys, no, 
l'analisi e` stata fatta (non dall'OP, sia chiaro) in modo farlocco
 
Enrico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQEcBAEBAgAGBQJPJEo1AAoJED3SMOGZLYdYwk4H+gOFLCVHcshnHR99MG2dV9T2
fr4rQjch7BKqKuE6qoWMcZOXcpnUVQ488r66wK1MOseyxtlPi8o0pjItwU/cn3OV
wkMIH9kc2K/o0aN15glPXTOpPKivysvnJTUZzey0xHUXMUOsYcUxQ1XrffvhC0Rd
n8JaLqeWekQzUXdk7dlarBKwRb5xqIzpVtHsFrWcJoOrLKoys92UgZi41Pb14jx2
1Ege378lndUQAdpQ0t5Lt032LrzmvC1uvYE+rHDNBeUWeqYKtPWdZjXWv07J2vKp
ACbjYD/39LoolYWoqcIFI6iZBkmZ3AnCf0N3gWA2TUkSlyRaYokQoKVw6sfuTDY=
=fCoX
-----END PGP SIGNATURE-----
 

 cambiare l'host di connessione a livello di PHP.
 
Vero, ma l'iterazione dei dati (perche` prima o poi quei dati dovrai pur 
vederli ;) ) diverrebbe problematica. Al massimo, puoi pensare di creare uno 
database comune in cui i dati andranno a relazionarsi tra di loro, ma rimane 
comunque una gestione rognosa. L'unica e` rivedere tutto il progetto, a 
partire dalla struttura del database
 
Enrico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
 
iQEcBAEBAgAGBQJPJE9zAAoJED3SMOGZLYdYGUEH/3AsduopToEimrilQcNLUAqB
VfsDiR6CJe4udp4VVsyTXYSa+IhsbwZSG0R1EvRB6ba+0S1oJ6Q9UmBv5EC70k0E
KZimcvqZzlOX1wwtTQmH5mumOyiHuzZkIJH3SqCqJ6Ut/BIxv8YrdfLloz0yGRcp
a+dBa3aODerSs1qCndOyPM8uDGx2KSYs9gglrtNH2/PQ3BSSsPgH2kjPOMoQuBsO
R767mjI6SbH8WDMBxZFuUHmvScSzyQsrIp90X6OHLnjuQsQiKYKNgCaxETGZIue5
N7nIa7dssRSWBvvUF3UPa/xyQXIgDTewk4OnmtTUzjtHHK8OJgLiJJajjnSbnRo=
=Fix9
-----END PGP SIGNATURE-----
 

 partire dalla struttura del database
 
No, tra di loro i dati non dovranno mai essere correlati.
Utente1 non dovrà mai sapere cosa combina utente2.
Questo è poco ma sicuro.
 
Al limite, potrei essere io a dover estrapolare dei dati, ma in questa
remota (più unica che rara) possibilità, posso benissimo fare uno
script.


 Dal codice che posti sembra che tu abbia un singolo server.
 
Al momento singolo server.
A breve server multipli.
