cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mason Hale <>
Subject Re: Regarding Cassandra Scalability
Date Sun, 18 Apr 2010 13:00:24 GMT
On Sun, Apr 18, 2010 at 7:41 AM, Gary Dusbabek <> wrote:

> On Sat, Apr 17, 2010 at 10:50, dir dir <> wrote:
> >
> > What problems can’t it solve?
> >
> > No flexible indices
> > No querying on non PK values
> > Not good for binary data (>64mb) unless you chunck
> > Row contents must fit in available memory
> >
> > Gary Dusbabek say: Row contents must fit in available memory. Honestly I
> do
> > not understand
> > the meaning from that statement. Thank you.
> >
> > Dir.
> >
> The main reason is that the compaction operation (removing deleted
> values) currently requires that an entire row be read into memory.
> Gary Dusbabek

This is a statement I wish I had run across sooner. Our first implementation
(which we're changing now) included some very big rows. We ran into trouble
with compaction and during hinted hand-off operations (which also deals with
data a full row at a time) because these rows would not fit into available

I think until there are not these lurking gotcha spots like compaction and
hinted hand-off, where a full row must fit in memory, we should not be
making misleading statements like "Cassandra has the advantage of a more
advanced datamodel, allowing for a single row to contain billions of
column/value pairs: enough to fill a machine." (from: , A statement
like that should have some caveats, otherwise it reads as an endorsement, a
suggestion even, to build a data model with massively wide rows. In
practice, it is not feasible to have billions of columns in a single row
because it will lead to problems with compaction and hinted hand-off, maybe


View raw message