read together. If you are going
to query for all of them at the same time anyways, this disadvantage does not
apply to you.
- Original Message -
From: "Alvin UW"
To: user@cassandra.apache.org
Sent: Thursday, August 25, 2011 5:11:07 PM
Subject: Re: Customized Secondary Index Sche
User_Keys_By_Last_Name_alden. You can keep the matching main column family
> key as the column name. This will ensure that your index is evenly
> distributed throughout your cluster.
>
> - Original Message -
> From: "Ed Anuff"
> To: user@cassandra.apache.org
mn family
> key as the column name. This will ensure that your index is evenly
> distributed throughout your cluster.
>
> - Original Message -
> From: "Ed Anuff"
> To: user@cassandra.apache.org
> Sent: Thursday, August 25, 2011 12:48:49 PM
> Subject: R
st 25, 2011 12:48:49 PM
Subject: Re: Customized Secondary Index Schema
How many unique last names do you anticipate having? How many characters in the
last name do you anticipate keeping in your index? You can easily do the math
to figure out how many you could fit on a node. I think you'
How many unique last names do you anticipate having? How many characters in
the last name do you anticipate keeping in your index? You can easily do
the math to figure out how many you could fit on a node. I think you'll
find that the ceiling might be quite a bit higher than you think. If you
h
Yes, this is what I am worrying about.
2011/8/24 Ryan King
> On Tue, Aug 23, 2011 at 10:03 AM, Alvin UW wrote:
> > Hello,
> >
> > As mentioned by Ed Anuff in his blog and slides, one way to build
> customized
> > secondary index is:
> > We use one CF, each row to represent a secondary index, wi
On Tue, Aug 23, 2011 at 10:03 AM, Alvin UW wrote:
> Hello,
>
> As mentioned by Ed Anuff in his blog and slides, one way to build customized
> secondary index is:
> We use one CF, each row to represent a secondary index, with the secondary
> index name as row key.
> For example,
>
> Indexes = {
> "
Thanks.
2011/8/24 aaron morton
> IMHO it's only a scalability problem if those nodes have trouble handling
> the throughput. The load will go all all replicas, not one, unless you turn
> off Read Repair.
>
> If it is a problem then you could manually partition the index into
> multiple rows, bit
IMHO it's only a scalability problem if those nodes have trouble handling the
throughput. The load will go all all replicas, not one, unless you turn off
Read Repair.
If it is a problem then you could manually partition the index into multiple
rows, bit of a pain thought. I'd wait and see, or
