Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of sylvain@datastax.com
 designates 209.85.213.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CANc7xKW66XFmS=a8PikmE6mGuGKwkqi3FxENABGpKVtuvhn6gA@mail.gmail.com>
References: 
 <CANc7xKW66XFmS=a8PikmE6mGuGKwkqi3FxENABGpKVtuvhn6gA@mail.gmail.com>
From: Sylvain Lebresne <sylvain@datastax.com>
Date: Fri, 4 Nov 2011 15:27:41 +0100
Message-ID: 
 <CAKkz8Q3vtMkaW3g16CaCiE3QH3sOkZfUH6Si45ZtJkb7mXUg_w@mail.gmail.com>
Subject: Re: Why SSTable is sorted by tokens instead of row keys?
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 4, 2011 at 1:49 PM, Gary Shi <garyshi@gmail.com> wrote:
> I want to save time series event logs into Cassandra, and I need to load
> them by key range (row key is time-based). But we can't use
> RandomPartitioner in this way, while OrderPreservingPartitioner leads to hot
> spot problem.
>
> So I wonder why Cassandra save SSTable by sorted row tokens instead of keys:
> if rows in SSTable are sorted by keys, it should be quite easy to return
> rows by key range -- token should be used to determine which node contains
> the data. For key range requests, Cassandra could ask every node for that
> range of rows, merge them and return to the caller.

Without going for exhaustiveness:
- Requesting every node is not too scalable. Cassandra is built to target the
'lots of cheap machines' kind of cluster, so that kind of operation is going the
exact opposite way. In other words, that would be slow enough that you're
better off modeling this using columns for time series.
- That would make topology operations (bootstrap, move, decommission)
much  more costly, because we wouldn't be able to tell which keys to move
unless we iterate over all the data each time.

--
Sylvain

>
> --
> regards,
> Gary Shi
>