Comments on: Cassandra Internals – Reading

By: Yaron

Yaron — Tue, 31 May 2011 15:16:29 +0000

Hi,
I’m trying to figure out the eventually consistent property, and I don’t understand something:
You wrote that the quorum level “waits for a majority to respond with the same value”. I think that is not true. It waits for an R nodes to return a value and then return the most recent one. Otherwise, the R+W>=N property does not hold.

By: Cassandra Reads Performance Explained | All in one for social - Blog

Cassandra Reads Performance Explained | All in one for social - Blog — Mon, 08 Nov 2010 07:58:04 +0000

[...] a comment08/11/2010 Number of View: 4After explaining Cassandra writes performance, Mike Perham ☞ continues his series now explaining: “reads and […] why they are slow”.So what happens with a [...]

By: Cassandra内部机制 : 读操作 « a db thinker's home

Cassandra内部机制 : 读操作 « a db thinker's home — Sun, 30 May 2010 14:17:28 +0000

[...] : 读操作 Cassandra内部机制 : 读操作 By Mike Perham Translated By [...]

By: OCTO talks ! » no:sql(eu) et NoSQL : qu’en est il?

OCTO talks ! » no:sql(eu) et NoSQL : qu’en est il? — Thu, 22 Apr 2010 17:46:16 +0000

[...] pour l’écriture. Par exemple, Cassandra réalise plus d’accès disque pour une lecture que pour une [...]

By: Cheatsheet: 2010 04.01 ~ 04.07 - gOODiDEA.NET

Cheatsheet: 2010 04.01 ~ 04.07 - gOODiDEA.NET — Wed, 07 Apr 2010 02:38:50 +0000

[...] Cassandra Internals – Reading – Cassandra Reads Performance Explained [...]

By: Mike Perham

Mike Perham — Thu, 18 Mar 2010 15:46:27 +0000

Thanks for the corrections, Jonathan. That’s the horse’s mouth, people, believe him not me.

By: Jonathan Ellis

Jonathan Ellis — Thu, 18 Mar 2010 15:38:51 +0000

I find that saying “they will all eventually return “456″ but it is not guaranteed when” scares people unnecessarily. “Eventually” means “typically, small numbers of ms.” It’s exactly like doing reads in an environment with MySQL replication, or Slony for PostgreSQL, except that Cassandra can handle replication hiccups better.

The reason uncached reads are slower in Cassandra is not because the sstable is inherently io-intensive (it’s actually better than b-tree based storage on a 1:1 basis) but because in the average case you’ll have to merge row fragments from 2-4 sstables to complete the request, since sstables are not update-in-place.

Also, explaining that “uncached reads are slow in Cassandra [compared to writes]” is only half the story, because Cassandra’s built in caches can make reads very very fast, fast enough that Digg dropped memcached entirely from their architecture.