3 ms·

"To deliver the highest write performance, Couchbase Server writes to an integrated, in-memory cache first. Then, it synchronizes the cache with the storage dev

by meritt 12y ago

"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

skjhn 12y ago
That's right, and the same is true for MongoDB and Cassandra. They do not fsync on writes and they replicate asynchronously.
regularfry 12y ago
I'm intrigued as to how one can possibly justify calling that a "write".
- skjhn 12y ago
  Because the data is written to a data structure before the write completed. You can "write" to a cache or to an in-memory database. Databases, relational or NoSQL, write to memory first whether it is to an application managed cache or an OS managed cache (i.e. page cache).
Dave_R 12y ago
So by default when the SDK returns 'true' for a write, yes it's just been written to RAM on the first (master) node. However you can if you desire 'observe' the write, which will return true when the write has hit disk and/or the RAM of the replica nodes (depending on what options you specify). 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).

by meritt 12y ago

skjhn 12y ago

That's right, and the same is true for MongoDB and Cassandra. They do not fsync on writes and they replicate asynchronously.

regularfry 12y ago

I'm intrigued as to how one can possibly justify calling that a "write".

skjhn 12y ago
Because the data is written to a data structure before the write completed. You can "write" to a cache or to an in-memory database. Databases, relational or NoSQL, write to memory first whether it is to an application managed cache or an OS managed cache (i.e. page cache).

Dave_R 12y ago

So by default when the SDK returns 'true' for a write, yes it's just been written to RAM on the first (master) node. However you can if you desire 'observe' the write, which will return true when the write has hit disk and/or the RAM of the replica nodes (depending on what options you specify). 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).