rilevante

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.

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
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.

Fabio Ferrero ha scritto:
> 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.
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.

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
CouchDB? O addirittura key-value stores come MemcacheDB, Cassandra, ecc.?

Bye.

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

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)

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.

> 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)

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.

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,
>> 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
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.

Anche io ho ho inteso cosi'.

> 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.

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.

Ciao.

-----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

-----BEGIN PGP SIGNED MESSAGE-----
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
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.

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 'Henryx' Bianchi ha scritto:
> 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.
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.

Alessandro Pellizzari ha scritto:
> 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.
A breve server multipli.