Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of feestend@gmail.com designates
 209.85.214.44 as permitted sender)
MIME-Version: 1.0
Date: Wed, 16 May 2012 13:58:31 +0200
Message-ID: 
 <CAPjXCuw7+maeHmf4aQ93thdy3xPs4JbKE6VKFomiNChV4NQZ8Q@mail.gmail.com>
Subject: understanding of native indexes: limitations,
 potential side effects,...
From: David Vanderfeesten <feestend@gmail.com>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=0015175cba84b84b5e04c0260955

--0015175cba84b84b5e04c0260955
Content-Type: text/plain; charset=ISO-8859-1

Hi

I like to better understand the limitations of native indexes, potential
side effects and scenarios where they are required.

My understanding so far :
- Is that indexes on each node are storing indexes for data locally on the
node itself.
- Indexes do not return values in a sorted way (hashes of the indexed row
keys are defining the order)
- Given by the design referred in the first bullet, a coordinator node
receiving a read of a native index, needs to spawn a read to multiple
nodes(set of nodes together covering at least the complete key space +
potentially more to assure read consistency level).
- Each write to an indexed column leads to an additional local read of the
index to update the index (kind of obvious but easily forgotten when tuning
your system for write-only workload)
- When using a where clause in CQL you need at least to specify an equal
condition on a native indexed column. Additional conditions in the where
clause are filtered out by the coordinator node receiving the CQL query.
- native indexes do not support very well columns with high number of
discrete values throughout the entire CF.

Is upper understanding correct and complete?
Some doubts:
- about the limitation of indexing columns with high number of discrete
values:
I assume native indexes  are implemented with an internally managed CF per
index. With high cardinality values, in worst case, the number of rows in
the index are identical to the number of rows of the indexed CF. Or are
there other reasons for the limitation, and if that's the case, is there a
guideline on the max. nbr of cardinality that is still reasonable?
-Are column updates and the update of the indexes (read + write action)
atomic and isolated from concurrent updates?

Txs!

David

--0015175cba84b84b5e04c0260955
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi<br><br>I like to better understand the limitations of native indexes, po=
tential side effects and scenarios where they are required.<br><br><span cl=
ass=3D"st">My understanding so far :<br>
- Is that indexes on each node are storing indexes for data locally on the =
node itself.<br>- Indexes do not return values in a sorted way (hashes of t=
he indexed row keys are defining the order)<br>- Given by the design referr=
ed in the first bullet, a coordinator node receiving a read of a native ind=
ex, needs to spawn a read to multiple nodes(set of nodes together covering =
at least the complete key space + potentially more to assure read consisten=
cy level). <br>

- Each write to an indexed column leads to an additional local read of the =
index to update the index (kind of=20
obvious but easily forgotten when tuning your system for write-only=20
workload)</span><br>- When using a where clause in CQL you need at least to=
 specify an equal condition on a native indexed column. Additional conditio=
ns in the where clause are filtered out by the coordinator node receiving t=
he CQL query.<br>
- native indexes do not support very well columns with high number of discr=
ete values throughout the entire CF.<br><br>Is upper understanding correct =
and complete? <br>Some doubts: <br>- about the limitation of indexing colum=
ns with high number of discrete values: <br>
I assume native indexes=A0 are implemented with an internally managed CF pe=
r index. With high cardinality values, in worst case, the number of rows in=
 the index are identical to the number of rows of the indexed CF. Or are th=
ere other reasons for the limitation, and if that&#39;s the case, <span cla=
ss=3D"st">is there a guideline on the max. nbr of cardinality that is still=
 reasonable? </span><br>
-Are column updates and the update of the indexes (read + write action) ato=
mic and isolated from concurrent updates? <br><br><span class=3D"st">Txs!<b=
r><br>David<br><br><br><br><br></span>

--0015175cba84b84b5e04c0260955--