Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
Sender: scode@scode.org
In-Reply-To: <4C977450.5030908@corp.aol.com>
References: <4C977450.5030908@corp.aol.com>
Date: Mon, 20 Sep 2010 18:47:12 +0200
Message-ID: <AANLkTimrPfYEUsnUP-MO_JMmYuxGu6U3qKM9v1Pbfja+@mail.gmail.com>
Subject: Re: improving read performance
From: Peter Schuller <peter.schuller@infidyne.com>
To: dev@cassandra.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> This drawback is unfortunate for systems that use time-based row keys. =
=C2=A0 =C2=A0In
> such systems, row data will generally not be fragmented very much, if at
> all, but reads suffer because the assumption is that all data is fragment=
ed.
> =C2=A0 =C2=A0Even further, in a real-time system where reads occur quickl=
y after
> writes, if the data is in memory, the sstables are still checked.

Perhaps I am misunderstanding you, but why is this a problem (in the
particular case of time based row keys) given that existence of the
bloom filters which should eliminate the need to go down to the
sstables to any extent more than that they actually contain data for
the row (in almost all cases, subject to bloom filter false
positives)?

Also, for the case of the edges where memtables are flushed, a
write-through row cache should help alleviate that. I forget off hand
whether the row cache is in fact write-through or not though.

--=20
/ Peter Schuller