41–50 of 55 posts
"To deliver the highest write performance, Couchbase Server writes to an integrated, in-memory cache first. Then, it synchronizes the cache with the storage device for durability." Comparing the write speed of non-durable writes against the write speed of durable writes is the same bullshit tactic that MongoDB first utilized a few years ago. Why don't we just add /dev/null in there too? We're also apparently using 2…
I'm intrigued as to how one can possibly justify calling that a "write".
Earlier quoted context omitted.
Of course they are not durable until fsync; that is why having an upper bound on how long that will be is important. Out of the box Cassandra defaults to an upper bound of 10s. Couchbase defaults to no upper bound at all -- you can lose arbitrary amounts of data on power loss. That's a huge difference. Since Couchbase does not support a time bound on fsyncs, there are two ways to make a fair comparison: make both sys…
As can Cassandra. It depends on how much data is still in the page cache. I do agree both systems can be configured for immediate durability. However, we went with the default values as most people (and most databases) do not sync on every write. It is too much of a performance cost.
Its "MongoDB is web-scale" all over again.
http://couchdb.readthedocs.org/en/latest/config/couchdb.html
You can then disable that if you don't care but it. So don't confuse Couchbase's policy with CouchDB (Couchdbase it seems has gone the way of Mongo here).
Also couchdb writes in append only mode and will let you crash restart your server without corrupting your data.
Earlier quoted context omitted.
Hi, thanks a lot for posting this! I have been thinking about using Couchbase Server for a mobile project because I like the mobile client component they have. I'm particularly concerned about the "opaque administration" issue - have you had to actually pay the company [1] for support because the log output is so bad, or did it just slow down your debugging process. [1] I have nothing against paying for support, but…
I don't have a problem with charging for support either, but Couchbase (for us) is just a memcache replacement, so that price is too high to justify. Without support the "debugging process" consists of blindly trying random things to fix the problem before giving up and moving on to something else.
"To deliver the highest write performance, Couchbase Server writes to an integrated, in-memory cache first. Then, it synchronizes the cache with the storage device for durability." Comparing the write speed of non-durable writes against the write speed of durable writes is the same bullshit tactic that MongoDB first utilized a few years ago. Why don't we just add /dev/null in there too? We're also apparently using 2…
Ultimately it's a performance tradeoff - if you want sub microsecond writes for your workload then something has to give - certainly for many workloads (session stores, ad tracking, messaging queues) the tradeoff that you may loose the last few writes if you loose a node and it's replicas simultaneously is an acceptable one.
(Full disclosure: I work for Couchbase).
My problems with Couchbase: - Completely opaque administration. The company charges for support ($5k per production node per year!), so perhaps unsurprisingly the log output is unreadable (similar to a binary stacktrace). Forget about diagnosing cluster issues on your own. - Bizarre failover behavior. In every test scenario I've tried, if any single node goes down my application becomes unresponsive (even if it can s…
Hi, thanks a lot for posting this! I have been thinking about using Couchbase Server for a mobile project because I like the mobile client component they have. I'm particularly concerned about the "opaque administration" issue - have you had to actually pay the company [1] for support because the log output is so bad, or did it just slow down your debugging process. [1] I have nothing against paying for support, but…
If you are considering a scalable solution, you can use DataStax Enterprise for free in production if you are a startup (under $20M raised and under $2M in annual revs). Check here: http://www.datastax.com/what-we-offer/products-services/data...
>However, MongoDB implements a single lock per database (link). MongoDB nodes are limited to executing a single write at a time per database.
that sounds like a nightmare. Are they for real?
Looking at the results - durable configs, MongoDB and DataStax, have 3ms latency with 25K and 75K ops/sec. Are they using HDDs or SSDs? As a reference point - 5 years ago I was hitting 3.5ms on 15K disks on Oracle, at 20-30K ops/second (durable).
>*Couchbase sponsored this study.
priceless.