Here is my own experience testing couchdb versus cassandra for an internal application.
My test wasn't some dummy test case, it was realistic workloads that is 95% write and 5% read. We insert data in batches to maximize throughput. The critical thing for my use case was to answer "when does the server crash and what happens?" Each row was approximately 4-8K. I tested with a variety of batch sizes and found that couchdb choked around 20K rows of data. When I looked at couchdb logs, there was no indication of why it crashed or what caused it. I tested cassandra up to 50K rows per batch and didn't have time to reach the failure point. The troubling issue for me is the lack of information on the cause of the crash. All server crash at some point. Having details on why and how it crashed to me is critical to debugging and improving performance. Having zero indication for me suggests major architectural flaws and issues in the design and implementation. I haven't had time to investigate the real cause, since the logs didn't give any hint. If the log had details, I would have atleast taken a look at the source file and try to debug it. On Mon, Oct 1, 2012 at 11:05 AM, Andy Cobley <acob...@computing.dundee.ac.uk> wrote: > There are some interesting results in the benchmarks below: > > http://www.slideshare.net/renatko/couchbase-performance-benchmarking > > Without starting a flame war etc, I'm interested if these results should > be considered "Fair and Balanced" or if the methodology is flawed in some > way ? (for instance is the use of Amazon EC2 sensible for Cassandra > deployment) ? > > Andy > > > > The University of Dundee is a Scottish Registered Charity, No. SC015096. > >
