Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Performance: database multipli o partizionamento?
199 views
Skip to first unread message
Gandalf Corvotempesta
Jan 27, 2012, 5:11:00 AM1/27/12
to
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!
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!
Fabio Ferrero
Jan 27, 2012, 6:33:54 AM1/27/12
to
On 27/01/12 11:11, Gandalf Corvotempesta wrote:
> 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?
Non sono un guru dei database ma secondo me la risposta e': nessuna
> 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?
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...
Gandalf Corvotempesta
Jan 27, 2012, 6:45:20 AM1/27/12
to
Fabio Ferrero ha scritto:
Parto già con svariati milioni di record, che aumenteranno di molto
nel giro di poche settimane.
> Dividere i db non lo farei neppure sotto tortura...
Perchè ? Ha una scalabilità eccellente (probabilmente la migliore) e
si può implementare, a livello applicativo, con circa 2 righe di codice
(nel mio caso specifico)
> 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.
MySQL, tutte tabelle innodb, ed il 90% delle query sono INSERT,
il restante 10% sono SELECT su chiave primaria.
> Eventualmente valuterei servizi specifici tipo RDS di amazon.
L'esternalizzazione dei dati è esclusa.
> 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).
Nel mio caso i dati possono solo aumentare, non diminuiranno mai.
> 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).
Parto già con svariati milioni di record, che aumenteranno di molto
nel giro di poche settimane.
> Dividere i db non lo farei neppure sotto tortura...
si può implementare, a livello applicativo, con circa 2 righe di codice
(nel mio caso specifico)
> 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.
il restante 10% sono SELECT su chiave primaria.
> Eventualmente valuterei servizi specifici tipo RDS di amazon.
Alessandro Pellizzari
Jan 27, 2012, 7:16:50 AM1/27/12
to
Il Fri, 27 Jan 2012 12:45:20 +0100, Gandalf Corvotempesta ha scritto:
> MySQL, tutte tabelle innodb, ed il 90% delle query sono INSERT, il
> restante 10% sono SELECT su chiave primaria.
Se questo e` il tuo scenario, hai valutato DB NoSQL come MongoDB e
> MySQL, tutte tabelle innodb, ed il 90% delle query sono INSERT, il
> restante 10% sono SELECT su chiave primaria.
CouchDB? O addirittura key-value stores come MemcacheDB, Cassandra, ecc.?
Bye.
Gandalf Corvotempesta
Jan 27, 2012, 9:04:01 AM1/27/12
to
Alessandro Pellizzari ha scritto:
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)
> Se questo e` il tuo scenario, hai valutato DB NoSQL come MongoDB e
> CouchDB? O addirittura key-value stores come MemcacheDB, Cassandra, ecc.?
Si. Significa rifare tutto, ma proprio tutto
> CouchDB? O addirittura key-value stores come MemcacheDB, Cassandra, ecc.?
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)
Alessandro Pellizzari
Jan 27, 2012, 12:51:13 PM1/27/12
to
Il Fri, 27 Jan 2012 15:04:01 +0100, Gandalf Corvotempesta ha scritto:
> Alessandro Pellizzari ha scritto:
>> Se questo e` il tuo scenario, hai valutato DB NoSQL come MongoDB e
>> CouchDB? O addirittura key-value stores come MemcacheDB, Cassandra,
>> ecc.?
>
> Si. Significa rifare tutto, ma proprio tutto
Sorry, avevo capito che era un progetto che doveva partire.
> Alessandro Pellizzari ha scritto:
>> Se questo e` il tuo scenario, hai valutato DB NoSQL come MongoDB e
>> CouchDB? O addirittura key-value stores come MemcacheDB, Cassandra,
>> ecc.?
>
> Si. Significa rifare tutto, ma proprio tutto
> 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)
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.
Fabio Ferrero
Jan 28, 2012, 5:17:51 AM1/28/12
to
On 27/01/12 18:51, Alessandro Pellizzari wrote:
>>> Se questo e` il tuo scenario, hai valutato DB NoSQL come MongoDB e
>>> CouchDB? O addirittura key-value stores come MemcacheDB, Cassandra,
>>> Se questo e` il tuo scenario, hai valutato DB NoSQL come MongoDB e
>>> CouchDB? O addirittura key-value stores come MemcacheDB, Cassandra,
>> Si. Significa rifare tutto, ma proprio tutto
> Sorry, avevo capito che era un progetto che doveva partire.
In effetti questo punto non e' chiaro... in fase di analisi non c'era
> Sorry, avevo capito che era un progetto che doveva partire.
questa esigenza di avere decine di milioni di record?
> 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.
funzionera' meglio di quello che puo' gia' fare il db, che nasce per
questi compiti. Eventualmente si lavora di ottimizzazioni.
Enrico 'Henryx' Bianchi
Jan 28, 2012, 2:19:16 PM1/28/12
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fabio Ferrero wrote:
> In effetti questo punto non e' chiaro... in fase di analisi non c'era
> 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-----
Hash: SHA1
Fabio Ferrero wrote:
> In effetti questo punto non e' chiaro... in fase di analisi non c'era
> questa esigenza di avere decine di milioni di record?
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-----
Enrico 'Henryx' Bianchi
Jan 28, 2012, 2:41:39 PM1/28/12
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hash: SHA1
Gandalf Corvotempesta wrote:
> sarebbe opportuno
> partizionare i dati oppure creare database multipli divisi per utente?
Partizionare i dati. Creare piu` database per utente (anche se c'e` da dire
> sarebbe opportuno
> partizionare i dati oppure creare database multipli divisi per utente?
che il concetto di database su MySQL e` farlocco) secondo me signfica
introdurre un altro problema ad una architettura gia` problematica di suo
> 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.
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)
VfsDiR6CJe4udp4VVsyTXYSa+IhsbwZSG0R1EvRB6ba+0S1oJ6Q9UmBv5EC70k0E
KZimcvqZzlOX1wwtTQmH5mumOyiHuzZkIJH3SqCqJ6Ut/BIxv8YrdfLloz0yGRcp
a+dBa3aODerSs1qCndOyPM8uDGx2KSYs9gglrtNH2/PQ3BSSsPgH2kjPOMoQuBsO
R767mjI6SbH8WDMBxZFuUHmvScSzyQsrIp90X6OHLnjuQsQiKYKNgCaxETGZIue5
N7nIa7dssRSWBvvUF3UPa/xyQXIgDTewk4OnmtTUzjtHHK8OJgLiJJajjnSbnRo=
=Fix9
-----END PGP SIGNATURE-----
Gandalf Corvotempesta
Jan 30, 2012, 6:11:49 AM1/30/12
to
Enrico 'Henryx' Bianchi ha scritto:
Dopotutto, se hai da gestire milioni e milioni di dati, se non
splitti in qualche modo, diventi matto.
Anche come gestione, gestire 10 database, uno per utente, piuttosto che
50 milioni di record in una singola tabella, è ben diverso.
> 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
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.
> Partizionare i dati. Creare piu` database per utente (anche se c'e` da dire
> che il concetto di database su MySQL e` farlocco) secondo me signfica
> introdurre un altro problema ad una architettura gia` problematica di suo
Beh, lo sharding è pratica comune e non è una architettura farlocca.
> che il concetto di database su MySQL e` farlocco) secondo me signfica
> introdurre un altro problema ad una architettura gia` problematica di suo
Dopotutto, se hai da gestire milioni e milioni di dati, se non
splitti in qualche modo, diventi matto.
Anche come gestione, gestire 10 database, uno per utente, piuttosto che
50 milioni di record in una singola tabella, è ben diverso.
> 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
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.
Gandalf Corvotempesta
Jan 30, 2012, 6:12:17 AM1/30/12
to
Alessandro Pellizzari ha scritto:
A breve server multipli.
> Ma stai parlando di un singolo server o di server multipli?
> Dal codice che posti sembra che tu abbia un singolo server.
Al momento singolo server.
> Dal codice che posti sembra che tu abbia un singolo server.
A breve server multipli.
0 new messages