Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: Range deletes, wide partitions, and reverse iterators
From: Nitan Kainth <nitan@bamlabs.com>
In-Reply-To: <35D525BF-765D-4D5D-BFBD-A8A36EEC53BA@gmail.com>
Date: Tue, 16 May 2017 09:29:41 -0500
Cc: Stefano Ortolani <ostefano@gmail.com>, user@cassandra.apache.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <93D97AF4-758E-46D8-811F-CE3A9BAF7811@bamlabs.com>
References: <CAKy_EwaeUnPV_95osw0ohXe1nd6M=OX_T4X_6qshRcEA3PCcTA@mail.gmail.com> <35D525BF-765D-4D5D-BFBD-A8A36EEC53BA@gmail.com>
To: =?utf-8?Q?Hannu_Kr=C3=B6ger?= <hkroger@gmail.com>
archived-at: Tue, 16 May 2017 14:29:51 -0000

Hannu,

How can you read a partition in reverse?=20

Sent from my iPhone

> On May 16, 2017, at 9:20 AM, Hannu Kr=C3=B6ger <hkroger@gmail.com> wrote:
>=20
> Well, I=E2=80=99m guessing that Cassandra doesn't really know if the range=
 tombstone is useful for this or not.=20
>=20
> In many cases it might be that the partition contains data that is within t=
he range of the tombstone but is newer than the tombstone and therefore it m=
ight be still be returned. Scanning through deleted data can be avoided by r=
eading the partition in reverse (if all the deleted data is in the beginning=
 of the partition). Eventually you will still end up reading a lot of tombst=
ones but you will get a lot of live data first and the implicit query limit o=
f 10000 probably is reached before you get to the tombstones. Therefore you w=
ill get an immediate answer.
>=20
> Does it make sense?
>=20
> Hannu
>=20
>> On 16 May 2017, at 16:33, Stefano Ortolani <ostefano@gmail.com> wrote:
>>=20
>> Hi all,
>>=20
>> I am seeing inconsistencies when mixing range tombstones, wide partitions=
, and reverse iterators.
>> I still have to understand if the behaviour is to be expected hence the m=
essage on the mailing list.
>>=20
>> The situation is conceptually simple. I am using a table defined as follo=
ws:
>>=20
>> CREATE TABLE test_cql.test_cf (
>>  hash blob,
>>  timeid timeuuid,
>>  PRIMARY KEY (hash, timeid)
>> ) WITH CLUSTERING ORDER BY (timeid ASC)
>>  AND compaction =3D {'class' : 'LeveledCompactionStrategy'};
>>=20
>> I then proceed by loading 2/3GB from 3 sstables which I know contain a re=
ally wide partition (> 512 MB) for `hash =3D x`. I then delete the oldest _h=
alf_ of that partition by executing the query below, and restart the node:
>>=20
>> DELETE=20
>> FROM test_cql.test_cf=20
>> WHERE hash =3D x AND timeid < y;
>>=20
>> If I keep compactions disabled the following query timeouts (takes more t=
han 10 seconds to=20
>> succeed):
>>=20
>> SELECT *=20
>> FROM test_cql.test_cf=20
>> WHERE hash =3D 0x963204d451de3e611daf5e340c3594acead0eaaf=20
>> ORDER BY timeid ASC;
>>=20
>> While the following returns immediately (obviously because no deleted dat=
a is ever read):
>>=20
>> SELECT *=20
>> FROM test_cql.test_cf=20
>> WHERE hash =3D 0x963204d451de3e611daf5e340c3594acead0eaaf=20
>> ORDER BY timeid DESC;
>>=20
>> If I force a compaction the problem is gone, but I presume just because t=
he data is rearranged.
>>=20
>> It seems to me that reading by ASC does not make use of the range tombsto=
ne until C* reads the
>> last sstables (which actually contains the range tombstone and is flushed=
 at node restart), and it wastes time reading all rows that are actually not=
 live anymore.=20
>>=20
>> Is this expected? Should the range tombstone actually help in these cases=
?
>>=20
>> Thanks a lot!
>> Stefano
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: user-help@cassandra.apache.org
>=20

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@cassandra.apache.org
For additional commands, e-mail: user-help@cassandra.apache.org