You know what would be a nice twist, if database vendors added jepsen runs to their benchmarking mix.
FoundationDB did just that: http://blog.foundationdb.com/call-me-maybe-foundationdb-vs-j...
MongoDB and DataStax, In the Rearview Mirror
31–40 of 55 posts
Re: MongoDB and DataStax, In the Rearview Mirror
#32That's odd. I was under the impression that DataStax Java drivers had knowledge of the cluster and so weren't sending requests to random nodes. http://www.datastax.com/doc-source/developer/java-apidocs/co...
Some drivers do. Some drivers don't. Before DataStax started providing their own driver, the default Cassandra driver didn't.
Re: MongoDB and DataStax, In the Rearview Mirror
#33Earlier quoted context omitted.
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.
Cassandra cannot lose more than 10s of data because it will slow down writes as necessary to make sure it does not. That's why comparing to a system that allows arbitrarily high data loss is unfair. People can and do run Cassandra with full durability. When people understand the tradeoff between performance and data loss on power failure, you'd be surprised how often they'll chose real durability. (And by batching co…
Do you place a maximum amount of data in that 10s window? If not, it too is arbitrary. I do think batching concurrent writes is nice.
Re: MongoDB and DataStax, In the Rearview Mirror
#34Earlier quoted context omitted.
Performance is a reflection of architecture. Better performance, better architecture. That, and you can never downplay performance.
Really? ... Really? I didn't know my local file server that I SCP things too is better architected than S3.
Good point. After all, most interactive applications read and write data from local files via SCP and S3.
Re: MongoDB and DataStax, In the Rearview Mirror
#35"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 replicas however is the write being confirmed prior to the replica? From Couchbase documentation: "When a client application writes data to a node, that data will be placed in a replication queue and then a copy will be sent to another node. The replicated data will be available in RAM on the second node and will be placed in a disk write queue to be stored on disk at the second node."
So a write in Couchbase only guarantees it has been written to RAM on the 1st node. There's no fsync nor replica-writes occurring at the time of write_success=true
Re: MongoDB and DataStax, In the Rearview Mirror
#36My 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…
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.
Re: MongoDB and DataStax, In the Rearview Mirror
#37"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…
That's right, and the same is true for MongoDB and Cassandra. They do not fsync on writes and they replicate asynchronously.
Re: MongoDB and DataStax, In the Rearview Mirror
#38OH HERE YOU GO, I found that impartiality you dropped on the floor
Re: MongoDB and DataStax, In the Rearview Mirror
#39"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".
Re: MongoDB and DataStax, In the Rearview Mirror
#40Earlier quoted context omitted.
Cassandra cannot lose more than 10s of data because it will slow down writes as necessary to make sure it does not. That's why comparing to a system that allows arbitrarily high data loss is unfair. People can and do run Cassandra with full durability. When people understand the tradeoff between performance and data loss on power failure, you'd be surprised how often they'll chose real durability. (And by batching co…
Do you place a maximum amount of data in that 10s window? If not, it too is arbitrary. I do think batching concurrent writes is nice.
Of course "limit by time" and "limit by data" are interchangeable; in practice "limit by time" is easier for operators to reason about.