On Fri, 13 Nov 2009 15:05:26 +0100, Manlio Perillo <manlio.peri...@gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Daniele Varrazzo ha scritto: >> [...] >> Certo: forse mi sono spiegato male: PG è un DB relazionale, lo >> padroneggio >> alla grande e si è rivelato adatto a tutti i sistemi a cui ho lavorato >> finora e a cui lavoro attualmente. >> >> Prendo atto che farlo scalare su più di una macchina sarebbe un problema >> e >> se mi trovassi nella necessità di doverlo fare valuterei se non fosse il >> caso di adottare un db diverso, "non classico", tra i tanti che ne stanno >> uscendo in giro. Questo parallelamente alle strategie applicabili >> "dentro" >> Postgres, che però vanno poco oltre la classica replica single-master >> multi-slave. >> > > Non direi che vanno "poco" oltre la replica single-master multi-slave. > > La pagina > http://www.postgresql.org/docs/8.4/interactive/high-availability.html > indica alcune alternative. > > Di queste la "Statement-Based Replication Middleware" mi sembra molto > interessate, e ci sono implementazioni disponibili come Pgpool-II. > > Se fai pochi INSERT/UPDATE/DELETE e molti SELECT dovrebbe essere la > soluzione ideale.
Mi sembrano tutte soluzioni che pongono parecchia pressione sul DBAdmin e più delle pezze che una soluzione definitiva a load-balancing/high-availability. In quali di quelle indicate aggiungere un nodo ad un cluster è un'operazione trasparente? Se sono basate su PG devono avere in qualche modo una replica almeno parziale (shard) di tutto il dataset (altrimenti addio integrità referenziale). Noi abbiamo un db relativamente piccolo, pochi tera e la tabella più grande di 60M di record, e fare una replica tra due macchine già ci costerebbe una giornata buona. Queste sono appunto misure disponibili e da prendere in considerazione, ma se devo anche pensare (come suggerito per la "Statement-Based Replication Middleware", che come dici sembra la più promettente) a "Also, care must be taken that all transactions either commit or abort on all servers, perhaps using two-phase commit", allora mi salta la maggior parte dell'eleganza di usare PG. Per ottenere certe feature ci sono delle rinunce da fare alla completezza del modello relazionale, che non può essere "shared nothing". Puoi rinunciare alle proprietà ACID (o insistere a usarle sebbene nella maniera più scomoda della 2PC), ma volendo puoi anche decidere di rinunciare ai Join e usare HBase/Cassandra. O alla struttura del tutto e usare MongoDB/CouchDB. O agli oggetti del tutto e usare Redis/Tokio Cabinet. Non me lo sono mica sposato, l'elefante :) Se lo devo frustare preferisco farmi un'analisi seria e decidere se ci sono strumenti migliori per il compito che dovessi avere. -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
