Comments on: CouchDB Performance

By: Gabriele Lana

Gabriele Lana — Mon, 01 Mar 2010 11:53:44 +0000

@markux Si negli ultimi mesi li ho usati entrambi (per progetti diversi ovviamente) purtroppo ho tratto una conclusione poco pratica: sono due storage "special purpose", ovvero molto adatti per determinati tipi di progetti e poco adatti per altri, per sapere se sono o meno adatti al tuo progetto li devi conoscere, a questo proposito ho pubblicato una presentazione su slideshare (couchdb-vs-mongodb)

By: markux

markux — Thu, 11 Feb 2010 23:45:49 +0000

ciao, ottimo articolo… hai provato anche mongoDB? da questi test e dalla documentazione mi sembra + completo, anche per sostituire un relazionale in molti applcativi

http://www.snailinaturtleneck.com/blog/?p=74

By: Andrea

Andrea — Thu, 28 Jan 2010 11:08:12 +0000

Ciao, conosci un progetto di Database Documentale interamente scritto in c#? Grazie.

By: Gabriele Lana

Gabriele Lana — Mon, 26 Oct 2009 17:23:52 +0000

@Franco
1) Per CouchDB mi sono organizzato io, le funzioni in javascript le testo unitariamente e poi le assemblo automaticamente prima del deployment (lo faccio con rake), in più faccio dei test end-to-end del database caricando dei documenti ad-hoc e verificando che l’output è quello atteso (lo faccio con rspec)
2) Sicuramente meno dispersa rispetto a quello che avviene di solito, visto che il linguaggio è unico e che il client può controllare direttamente tutto del server, compresa la creazione al volo delle view (ovviamente scritte in javascript)

By: Franco Lombardo

Franco Lombardo — Mon, 26 Oct 2009 15:51:52 +0000

Alcuni miei dubbi su map-reduce inglobate nel repository dei dati:
1) Come si fa a testarne la logica?
2) La logica applicativa non risulta dispersa (e magari duplicata) parte nel repository e parte nel programma “client”?

Grazie

Ciao

Franco

By: Gabriele Lana

Gabriele Lana — Mon, 26 Oct 2009 09:48:33 +0000

@Franco penso che ogni tecnologia ha la sua applicabilità, è la forza/condanna di strumenti come VisualBasic e Access, il mondo ha iniziato ad utilizzarli per quello che non erano, la Microsoft ha iniziato a trasformarli in ciò che non dovevano essere, alla fine sono diventati qualcosa di talmente bacato e complesso da scatenare l’odio da parte delle persone. Couchdb ad oggi ha il potenziale per poter risolvere in maniera semplice ed elegante una certa classe di problemi, facendo anche la scelta di usare javascript sia per il cliente che per il server, l’unica cosa per il momento è aspettare e vedere come lo faranno evolvere :-)

Nota: rispetto alle stored procedures il modello di CouchDB è assai più elegante, l’unica astrazione esistente è il documento, un documento può essere dato o procedura, nulla vieta di processare le procedure come dati per produrre dati o procedure, so che può sembrare complesso, in realtà rende il tutto molto semplice una volta che hai compreso i pochi concetti di base

By: Gabriele Lana

Gabriele Lana — Mon, 26 Oct 2009 09:30:54 +0000

@devsmt Grazie per i complimenti :-)

Per quanto riguarda il discorso convivenza del relazionale/documentale, ovviamente la risposta è “dipende”, in particolare dipende dalla natura dell’applicativo, se hai bisogno di una consistenza “forte” dei dati sopratutto per quanto riguarda la transazionalità del dato, penso che convenga restare sul db ralazione (ci sono modo di rigirare il problema nel mondo documentale, ex. basta creare un documento che rappresenta e che accumula tutti i dati della transazione). Ma se l’applicazione è il classico CRUD potresti scriverla tutta direttamente in CouchDB (http://github.com/jchris/couchapp) e vivresti una vita felice. Detto questo noi (http://www.yourank.it) stiamo facendo convivere il mondo relazionale con quello documentale senza grossi problemi, ma CouchDB guadagna sempre più terreno ;-)

By: devsmt

devsmt — Mon, 26 Oct 2009 08:30:56 +0000

interessantissimo e molto chiaro, come merita un argomento al limite dello sperimentale, ottimo anche l’accorgimento narrativo di una conclusione in cui esemplifichi con uno use-case molto favorevole.
mi sfugge, però, se per un sito dinamico ma diciamo tradizionalmente concepito, per intenderci basato su LAMP e organizzato secondo MVC, se il database relazionale va ad affiancare quello documentale o viene totalmente rimpiazzato e se l’elaborazione map/reduce che descrivi rimpiazza totalmente o si affianca all’elaborazione lato server.

grazie e complimenti per l’ottimo lavoro

By: Franco Lombardo

Franco Lombardo — Mon, 19 Oct 2009 16:50:06 +0000

Gabriele,
post molto interessante, come al solito. Due annotazioni

1) Mi sembra che una delle raccomandazioni per creare buone applicazioni che fanno uso di DB sia quella di evitare al massimo l’uso delle stored procedures. Il concetto di Map-Reduce, come introdotto in Couchdb, non si può intendere come un ritorno in grande stile delle stored procedures? L’uso si Javascript per queste funzioni mi lascia poi un poco perplesso.

2) Da sostenitore di AS400, ti ricodo che, oltre alle materialized views di Oracle, esistono anche le Materialized Query Table di DB2 (http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzajq/rzajqmqt.htm) :-)

Ciao

Franco