[Python] CouchDB [Was: "Go or Unladen Swallow? " Cosa ne pensate ?]

[Daniele Varrazzo]

On Fri, 13 Nov 2009 15:05:26 +0100, Manlio Perillo
<manlio.perillo a 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