Should I use CouchDb?

["Leonardo M. Ramé" <l....@griensu.com>]

Hi, yesterday a friend sent me an email about CouchDb, and I kept
reading about it until late night, it sounds like it could solve a
problem I'll have this next year.

Let me briefly explain what my company does, and the problem I'm facing.
The company let health organizations's (hospitals, clinics and
pharmacies) patients to pay by a local credit card, using our system, in
charge of credit validation.

Currently the software runs on a server supported by Firebird 2.1, and
health organizations ask for authorization by phone or internet (not all
organizations have internet access in this side of the world), that's
because at this time, all organizations are not too far from our
building, they are located in the same town.

In the near future, we are making arrangements with a couple of clinics
in other cities, and we want to let them to make authorizations online.
The problem here is we can't be sure the Internet access will be 100%
up, so I'm thinking of a multiple master redundancy schema, and after
reading about CouchDb, I think I found the solution to my problem.

Should I choose CouchDb? 

-- 
Leonardo M. Ramé
http://leonardorame.blogspot.com

Re: Should I use CouchDb?

[Jan Lehnardt <ja...@apache.org>]

Hi Markus,

that's good advice, thanks. And thanks for the plug :)

Cheers
Jan
--

On 10 Dec 2009, at 14:11, Markus Jelsma wrote:

> You should read throug the entire book but your questions are mostly
> answered in these chapters:
> - http://books.couchdb.org/relax/intro/eventual-consistency
> - http://books.couchdb.org/relax/reference/replication
> - http://books.couchdb.org/relax/reference/conflict-management
> 
> To summarize; CouchDB utilizes a non-locking multi version concurrency
> controler (MVCC) to allow for disconnected instances to CRUD the
> documents, which results in eventual consistency.
> 
> There exists no concept of locking but CouchDB's versioning system allows
> for handing document conflicts. These conflicts can and will rise in
> single but also multiple disconnected instances. In single instances the
> developer must provide the end-user with a mechanism to handle document
> conflicts or automate the process. During replication, CouchDB uses an
> arbitrary algorithm which choses a winner for conflicts.
> 
> CouchDB's conflict handling and versioning may be explained as somewhat
> similar to subversion and friends.
> 
> Although you may be very enthusiastic, you must read the book and forge
> some experiments for your use-case before actually going for it. There may
> be pitfalls.
> 
> In any case, the wiki's and this list will be helpful during your
> development.
> 
> 
> 
> 
> Leonardo M. Ramé wrote:
>> 
>> Knowing this, I seems that CouchDb is the way to go. In my model, each
>> health organization have a database server that must replicate its data
>> in planned intervals, twice a day for example.
>> 
>> This raises a question. Does the Replicator sends the whole database
>> from one server to another then do a diff between them?, or it has a
>> more lightweight approach?.
>> 
>> --
>> Leonardo M. Ramé
>> http://leonardorame.blogspot.com
> 
> 
> 

Re: Should I use CouchDb?

[Markus Jelsma <ma...@buyways.nl>]

You should read throug the entire book but your questions are mostly
answered in these chapters:
- http://books.couchdb.org/relax/intro/eventual-consistency
- http://books.couchdb.org/relax/reference/replication
- http://books.couchdb.org/relax/reference/conflict-management

To summarize; CouchDB utilizes a non-locking multi version concurrency
controler (MVCC) to allow for disconnected instances to CRUD the
documents, which results in eventual consistency.

There exists no concept of locking but CouchDB's versioning system allows
for handing document conflicts. These conflicts can and will rise in
single but also multiple disconnected instances. In single instances the
developer must provide the end-user with a mechanism to handle document
conflicts or automate the process. During replication, CouchDB uses an
arbitrary algorithm which choses a winner for conflicts.

CouchDB's conflict handling and versioning may be explained as somewhat
similar to subversion and friends.

Although you may be very enthusiastic, you must read the book and forge
some experiments for your use-case before actually going for it. There may
be pitfalls.

In any case, the wiki's and this list will be helpful during your
development.




Leonardo M. Ramé wrote:
>
> Knowing this, I seems that CouchDb is the way to go. In my model, each
> health organization have a database server that must replicate its data
> in planned intervals, twice a day for example.
>
> This raises a question. Does the Replicator sends the whole database
> from one server to another then do a diff between them?, or it has a
> more lightweight approach?.
>
> --
> Leonardo M. Ramé
> http://leonardorame.blogspot.com

Re: Should I use CouchDb?

[Matt Goodall <ma...@gmail.com>]

2009/12/10 Leonardo M. <l....@griensu.com>:
> El jue, 10-12-2009 a las 09:26 -0800, Chris Anderson escribió:
>> CouchDB is specifically designed for occasionally-connected use cases.
>> If you can fit your data model into CouchDB, then you should be able
>> to run it in multiple locations, and reconcile/update data with
>> replication when a network connection is available.
>
> Knowing this, I seems that CouchDb is the way to go. In my model, each
> health organization have a database server that must replicate its data
> in planned intervals, twice a day for example.
>
> This raises a question. Does the Replicator sends the whole database
> from one server to another then do a diff between them?, or it has a
> more lightweight approach?.

Just the changes, since last replication, are sent.

- Matt

Re: Should I use CouchDb?

["Leonardo M. Ramé" <l....@griensu.com>]

El jue, 10-12-2009 a las 09:26 -0800, Chris Anderson escribió:
> CouchDB is specifically designed for occasionally-connected use cases.
> If you can fit your data model into CouchDB, then you should be able
> to run it in multiple locations, and reconcile/update data with
> replication when a network connection is available. 

Knowing this, I seems that CouchDb is the way to go. In my model, each
health organization have a database server that must replicate its data
in planned intervals, twice a day for example.

This raises a question. Does the Replicator sends the whole database
from one server to another then do a diff between them?, or it has a
more lightweight approach?.

-- 
Leonardo M. Ramé
http://leonardorame.blogspot.com

Re: Should I use CouchDb?

[Chris Anderson <jc...@apache.org>]

2009/12/10 Leonardo M. <l....@griensu.com>:
> Hi, yesterday a friend sent me an email about CouchDb, and I kept
> reading about it until late night, it sounds like it could solve a
> problem I'll have this next year.
>
> Let me briefly explain what my company does, and the problem I'm facing.
> The company let health organizations's (hospitals, clinics and
> pharmacies) patients to pay by a local credit card, using our system, in
> charge of credit validation.
>
> Currently the software runs on a server supported by Firebird 2.1, and
> health organizations ask for authorization by phone or internet (not all
> organizations have internet access in this side of the world), that's
> because at this time, all organizations are not too far from our
> building, they are located in the same town.
>
> In the near future, we are making arrangements with a couple of clinics
> in other cities, and we want to let them to make authorizations online.
> The problem here is we can't be sure the Internet access will be 100%
> up, so I'm thinking of a multiple master redundancy schema, and after
> reading about CouchDb, I think I found the solution to my problem.
>
> Should I choose CouchDb?

CouchDB is specifically designed for occasionally-connected use cases.
If you can fit your data model into CouchDB, then you should be able
to run it in multiple locations, and reconcile/update data with
replication when a network connection is available.

>
> --
> Leonardo M. Ramé
> http://leonardorame.blogspot.com
>
>



-- 
Chris Anderson
http://jchrisa.net
http://couch.io