CouchDB vs RavenDB (Specific features)

[Ryan Zec <ba...@gmail.com>]

All,

I have been looking at a number of options for data storage for video game
meta data (high score lists (daily, weekly, monthly, all time, etc...),
other stats) and from what I can see I think the best option would be a
NoSQL Database.  The three major contenders so far are RavenDB, CouchDB, and
MongoDB.  I really like RavenDB however having to maintain one to multiple
windows server can be a bit expensive and I don't feel that RavenDB/Windows
would be much more stable than CouchDB/Linux or MongoDB/Linux to warrent the
cost.  I also don't quite know if I am going to developing the web
infrastructure in ASP.NET (if i did, it would make RavenDB the easy choice
for me).  That said there are a number of features of RavenDB that I really
like and was wondering if it was CouchDB has some of these features in one
way or another:

*Transactions
*This is kind of important for me.  An example would be sending scores to
the database.  When someone sends a score to the database, first I am going
to store that score as its own entity.  Then I am going to want to update
the record that stores the total for the day, week, month, etc...  If any
one of these updates fail, I don't want to any of the updates to save
(saving the insert is fine).  Is there a way to do this for CouchDB?

*Writing To Disk
*I really like that RavenDB by default writes to disk as it makes sure that
when data is sent to the server, the data will be there even if there is a
power outage or some other event that happens that is out or your control.
I would rather sacrifice a little write performance to maintain a much
better chance that data is not lost.  While that data I am storage is not
super mission critical (like payment information), it is still pretty
important to the players of the game and important if we want the meta game
to be successful.  Can CouchDB configured to write to disk instead of memory
(or does it do that be default)?

*Sharding
*From my understanding, CouchDB supports replication but not sharding out of
the box.  Are there any good sharding solutions for CouchDB?

*Auto Indexing
*One thing that is really nice with RavenDB is that is has auto index where
if you use an index that is not manually create a lot, RavenDB will
automatically turn the temporary index into an real index for you.  Can
CouchDB do this?

Any information about these features would be great.


Thanks,
Ryan Zec

Re: CouchDB vs RavenDB (Specific features)

[Robert Newson <rn...@apache.org>]

I don't think we should encourage the use of temporary views. I'm one
of the folks that wants to remove that feature once we develop a
suitable replacement (an in-browser 'view preview' simulator, for
example).

On 30 June 2011 09:21, Randall Leeds <ra...@gmail.com> wrote:
> On Mon, Jun 27, 2011 at 04:56, Sean Copenhaver
> <se...@gmail.com> wrote:
>>
>> *Auto Indexing
>> I'm guessing you are talking about if you can issue CouchDB a
>> dynamic/temporary view and if CouchDB will build and store the index. I
>> don't believe it does and when you issue the temporary view I believe
>> CouchDB basically does all the work and then throws it away. Those are
>> really meant for development/testing purposes.
>
> I believe the work is not thrown away until a view cleanup is
> requested. Identical temporary views should be fast and creating a
> permanent view with identical source should not require a full
> rebuild.
>
> -Randall
>

Re: CouchDB vs RavenDB (Specific features)

[Randall Leeds <ra...@gmail.com>]

On Mon, Jun 27, 2011 at 04:56, Sean Copenhaver
<se...@gmail.com> wrote:
>
> *Auto Indexing
> I'm guessing you are talking about if you can issue CouchDB a
> dynamic/temporary view and if CouchDB will build and store the index. I
> don't believe it does and when you issue the temporary view I believe
> CouchDB basically does all the work and then throws it away. Those are
> really meant for development/testing purposes.

I believe the work is not thrown away until a view cleanup is
requested. Identical temporary views should be fast and creating a
permanent view with identical source should not require a full
rebuild.

-Randall

Re: CouchDB vs RavenDB (Specific features)

[Sean Copenhaver <se...@gmail.com>]

When Ayende first started looking into document databases he actually read
the CouchDB source, so you'll find a lot of similarities between the two.
Now I believe you have to pay to use RavenDB for commercial purposes and
some of the official plug-ins are not available to the community edition. I
would double check on all that because a Window's license might not be the
only thing you have to think about.

*Transactions:
As they have said for aggregated amounts you can easily accomplish this with
a reduced view. If you wanted to keep up with the value inside another
document an update function could help you there.

Now CouchDB does have an 'all_or_nothing' option in it's bulk docs API.
Either all documents will be stored or non if there is a problem. This is
not really transactional as it does not handle conflicts so what wrote is
not what you would read. Once you started thinking about replication between
databases all semantics of transactions goes out the window anyway. I would
be curious if RavenDB maintains versioning on the documents and has to
handle conflicts, or if you would always have to lock the document to be
safe (does RavenDB does locking during transactions?).

Single document transaction sure. CouchDB does the whole append only b-tree,
so if it doesn't finish the commit to disk, it'll just go back to the last
completed write.

*Writing to disk
I don't have much to add, but I would certainly do some performance testing.
You can force each write to get flushed to disk and the difference between
that and automatic batching can be pretty substantial.

*Auto Indexing
I'm guessing you are talking about if you can issue CouchDB a
dynamic/temporary view and if CouchDB will build and store the index. I
don't believe it does and when you issue the temporary view I believe
CouchDB basically does all the work and then throws it away. Those are
really meant for development/testing purposes.


I would say the biggest draw for me (I'm a .NET programming by day) is that
RavenDB has first class .NET client with all the framework tie-ins and
idioms you would be accustom to. A big draw for me with CouchDB is that it
can be the center of my world (web server, database, simple middle tier,
simple auth). If I needed more back end process, then it can become a
message queue (_changes API makes this nice) or with HTTP proxying (new
feature in 1.1) the middle man.

On Mon, Jun 27, 2011 at 5:04 AM, Marcello Nuccio
<ma...@gmail.com>wrote:

> 2011/6/27 Ryan Zec <ba...@gmail.com>:
> > *Transactions
> > *This is kind of important for me.  An example would be sending scores to
> > the database.  When someone sends a score to the database, first I am
> going
> > to store that score as its own entity.  Then I am going to want to update
> > the record that stores the total for the day, week, month, etc...  If any
> > one of these updates fail, I don't want to any of the updates to save
> > (saving the insert is fine).  Is there a way to do this for CouchDB?
>
> I don't think you will need to store a record with the totals in CouchDB.
> You should use a view for that.
> http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views
>
>
> > *Writing To Disk
> > *I really like that RavenDB by default writes to disk as it makes sure
> that
> > when data is sent to the server, the data will be there even if there is
> a
> > power outage or some other event that happens that is out or your
> control.
> > I would rather sacrifice a little write performance to maintain a much
> > better chance that data is not lost.  While that data I am storage is not
> > super mission critical (like payment information), it is still pretty
> > important to the players of the game and important if we want the meta
> game
> > to be successful.  Can CouchDB configured to write to disk instead of
> memory
> > (or does it do that be default)?
>
> You can turn off delayed commits for maximum safety, but make sure to
> do some performance test.
> You can read about delayed commits at
> http://guide.couchdb.org/draft/performance.html#single
>
>
> > *Auto Indexing
> > *One thing that is really nice with RavenDB is that is has auto index
> where
> > if you use an index that is not manually create a lot, RavenDB will
> > automatically turn the temporary index into an real index for you.  Can
> > CouchDB do this?
>
> In CouchDB you build an index by adding a view, i.e. a Map function
> and, optionally, a Reduce function. So I don't think it is technically
> possible to automatically build it.
>
> ...just my 2cents.
>
> Marcello
>
> PS: I have never used RavenDB so I do not know how does it compare to
> CouchDB.
>



-- 
“The limits of language are the limits of one's world. “ -Ludwig von
Wittgenstein

Re: CouchDB vs RavenDB (Specific features)

[Marcello Nuccio <ma...@gmail.com>]

2011/6/27 Ryan Zec <ba...@gmail.com>:
> *Transactions
> *This is kind of important for me.  An example would be sending scores to
> the database.  When someone sends a score to the database, first I am going
> to store that score as its own entity.  Then I am going to want to update
> the record that stores the total for the day, week, month, etc...  If any
> one of these updates fail, I don't want to any of the updates to save
> (saving the insert is fine).  Is there a way to do this for CouchDB?

I don't think you will need to store a record with the totals in CouchDB.
You should use a view for that.
http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views


> *Writing To Disk
> *I really like that RavenDB by default writes to disk as it makes sure that
> when data is sent to the server, the data will be there even if there is a
> power outage or some other event that happens that is out or your control.
> I would rather sacrifice a little write performance to maintain a much
> better chance that data is not lost.  While that data I am storage is not
> super mission critical (like payment information), it is still pretty
> important to the players of the game and important if we want the meta game
> to be successful.  Can CouchDB configured to write to disk instead of memory
> (or does it do that be default)?

You can turn off delayed commits for maximum safety, but make sure to
do some performance test.
You can read about delayed commits at
http://guide.couchdb.org/draft/performance.html#single


> *Auto Indexing
> *One thing that is really nice with RavenDB is that is has auto index where
> if you use an index that is not manually create a lot, RavenDB will
> automatically turn the temporary index into an real index for you.  Can
> CouchDB do this?

In CouchDB you build an index by adding a view, i.e. a Map function
and, optionally, a Reduce function. So I don't think it is technically
possible to automatically build it.

...just my 2cents.

Marcello

PS: I have never used RavenDB so I do not know how does it compare to CouchDB.

Re: CouchDB vs RavenDB (Specific features)

[Ryan Zec <ba...@gmail.com>]

All,

I have been looking at a number of options for data storage for video game
meta data (high score lists (daily, weekly, monthly, all time, etc...),
other stats) and from what I can see I think the best option would be a
NoSQL Database.  The three major contenders so far are RavenDB, CouchDB, and
MongoDB.  I really like RavenDB however having to maintain one to multiple
windows server can be a bit expensive and I don't feel that RavenDB/Windows
would be much more stable than CouchDB/Linux or MongoDB/Linux to warrent the
cost.  I also don't quite know if I am going to developing the web
infrastructure in ASP.NET <http://asp.net/> (if i did, it would make RavenDB
the easy choice for me).  That said there are a number of features of
RavenDB that I really like and was wondering if it was CouchDB has some of
these features in one way or another:

*Transactions
*This is kind of important for me.  An example would be sending scores to
the database.  When someone sends a score to the database, first I am going
to store that score as its own entity.  Then I am going to want to update
the record that stores the total for the day, week, month, etc...  If any
one of these updates fail, I don't want to any of the updates to save
(saving the insert is fine).  Is there a way to do this for CouchDB?

*Writing To Disk
*I really like that RavenDB by default writes to disk as it makes sure that
when data is sent to the server, the data will be there even if there is a
power outage or some other event that happens that is out or your control.
I would rather sacrifice a little write performance to maintain a much
better chance that data is not lost.  While that data I am storage is not
super mission critical (like payment information), it is still pretty
important to the players of the game and important if we want the meta game
to be successful.  Can CouchDB configured to write to disk instead of memory
(or does it do that be default)?

*Sharding
*From my understanding, CouchDB supports replication but not sharding out of
the box.  Are there any good sharding solutions for CouchDB?

*Auto Indexing
*One thing that is really nice with RavenDB is that is has auto index where
if you use an index that is not manually create a lot, RavenDB will
automatically turn the temporary index into an real index for you.  Can
CouchDB do this?

Any information about these features would be great.

Re: CouchDB vs RavenDB (Specific features)

[Ladislav Thon <la...@gmail.com>]

Not a CouchDB expert, but I'll try...

*Transactions
> *This is kind of important for me.  An example would be sending scores to
> the database.  When someone sends a score to the database, first I am going
> to store that score as its own entity.  Then I am going to want to update
> the record that stores the total for the day, week, month, etc...  If any
> one of these updates fail, I don't want to any of the updates to save
> (saving the insert is fine).  Is there a way to do this for CouchDB?
>

CouchDB doesn't have transactions, but your usecase is easily solved using a
CouchDB view. I.e., you won't store these sums yourself, you will let
CouchDB compute them for you. See
http://wiki.apache.org/couchdb/HTTP_view_API.


> *Writing To Disk
> *I really like that RavenDB by default writes to disk as it makes sure that
> when data is sent to the server, the data will be there even if there is a
> power outage or some other event that happens that is out or your control.
> I would rather sacrifice a little write performance to maintain a much
> better chance that data is not lost.  While that data I am storage is not
> super mission critical (like payment information), it is still pretty
> important to the players of the game and important if we want the meta game
> to be successful.  Can CouchDB configured to write to disk instead of
> memory
> (or does it do that be default)?
>

CouchDB's append-only architecture means you don't have to worry about
losing data. If you switch delayed commits off, you will get fully ACID
operations.


> *Sharding
> *From my understanding, CouchDB supports replication but not sharding out
> of
> the box.  Are there any good sharding solutions for CouchDB?
>

You might want to look at CouchDB Lounge
http://tilgovi.github.com/couchdb-lounge/ (not sure if it is still
developed) or BigCouch (https://github.com/cloudant/bigcouch).


> *Auto Indexing
> *One thing that is really nice with RavenDB is that is has auto index where
> if you use an index that is not manually create a lot, RavenDB will
> automatically turn the temporary index into an real index for you.  Can
> CouchDB do this?
>

CouchDB in fact doesn't have indices, so this doesn't apply I guess. The
only way to query CouchDB is using views, there are no ad-hoc queries.
(Well, there are, but you have to use an external indexing/querying engine,
such as CouchDB Lucene or ElasticSearch).

LT