couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
Subject Re: Objective criteria
Date Thu, 14 Jan 2010 19:20:58 GMT
For the record, I do not think CouchDB is "fast enough", I know we tons of room for performance
improvement. If you believe that those involved with CouchDB do care about such things, you
are wrong. We care and are working on making it better. As Mikeal said, he is working on a
benchmarking stuff so we can measure CouchB performance under a lot of different loads, and
give feedback for how code changes affect the CouchDB performance profile. We have made this
a priority so that we can see objectively the performance of CouchDB. We are taking performance
seriously.

The issue here is how to use JIRA vs. the dev mailing list. JIRA is for specific bugs or patches,
not for generalized "it can be faster" issues. It can ALWAYS be faster, smaller, more available,
etc, that will never stop being true. But until you have an actual patch or have objectively
identified a bottle neck in the code, keep the discussions on the mailing list.

-Damien


On Jan 13, 2010, at 7:21 PM, Roger Binns wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Damien Katz wrote:
>>> That's fine, the issue is that bugs saying "It's too slow" is always true for
someone.
> 
> I did give specific numbers - ie 10 million documents, 2GB of JSON data etc
> and the amount of time taken as well as space.  I doubt you'd find anyone
> that considers 4 hours or 27GB to be reasonable numbers for that :-)
> 
>> Many people find the view indexing performance just fine, many do not.
> 
> True.  For example one of my other projects currently has 100 documents and
> I have no issue any part of CouchDB for that.
> 
> What isn't clear is statement of reasonable expectations - should I be able
> to handle 10 million documents in CouchDB?  Will it ever handle that?  Do
> you as the project leader care about that?  Everything has a sweet spot and
> I am not asking you to make 10 million documents be encompassed by the sweet
> spot, but clearly if you never intend for CouchDB to handle that much data
> then I need to go elsewhere.
> 
>>> Since CouchDB makes no performance or size guarantees,
> 
> How about publishing some?  Not guarantees but rather some expectations.
> For example if someone has 1GB of JSON data in 1 million documents what
> would be an expectation of size? The bugs can then be about substantial
> divergences from that.
> 
>> Unless you have specific bug to fix, or enhancement to make, don't use JIRA.
> 
> The issues you closed listed specific enhancements (pipelining, multiple
> instances, different file format etc).  I do acknowledge that I didn't
> supply code but I can't do everything :-)  All my personal projects are open
> source - it isn't like I am trying to take and never give.
> 
>>> Also, if you want something without view performance problems but similar to
CouchDB, you should look at MongoDB.
> 
> I did research the alternatives I could find.  CouchDB is the only solution
> that was designed for replication (and hence offline working, occasional
> disconnection, any topology for replication etc).  CouchDB is also the only
> one that allows for indices/views on data that is "calculated" rather than
> just extracting a particular value statically from the docs.  (That can be
> worked around by calculated values and shoving them into the docs but is
> less elegant.)
> 
> Other than that MongoDB seemed to be the nicest.  But I really want CouchDB
> to take over the world.  The concepts are right.  The replication point of
> view is right etc.  It not handling millions of documents in a reasonable
> amount of space and time is not right IMHO but I still don't know what the
> project opinion is.
> 
> Roger
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAktOjaUACgkQmOOfHg372QQBcACgmi/Rn5jtsiFvJZy0ksC6F6BU
> 8fMAn225w2RxsTKY8M/cg/29YSxc6mek
> =4qrM
> -----END PGP SIGNATURE-----
> 


Mime
View raw message