On Mon, 30 Jan 2012 11:14:37 -0600
Bryce Allen wrote:
> With RP, the idea is to query many versions in ListVersionIndex
> starting at the desired version going backward, hoping that it will
> hit a compact version. We could also maintain a separate
> CompactVersion index, and accept another query.
(not trolling) but do you have any ideas on how ?
The token produced by the partitioner is used as the key in the distributed
hash table so we can map keys to nodes, and evenly distribute load. If the
range of tokens for the DHT are infinite it's difficult to evenly map them to a
finite set o
two CFs, one for storing compacted complete
> > lists and one for storing deltas on the compacted list. Based on
> > usage, we will create a new compacted list and start writing deltas
> > against that. We should be able to limit the number of deltas in a
> > single row
On Sun, Jan 29, 2012 at 7:26 PM, aaron morton wrote:
> and compare them, but at this point I need to focus on one to get
> things working, so I'm trying to make a best initial guess.
>
> I would go for RP then, BOP may look like less work to start with but it
> *will* bite you later. If you use an
aintain that under all load scenarios. The compacted lists are
> straightforward, but there are many ways to structure the deltas and
> they all have trade offs. A CF with composite columns that supported
> two dimensional slicing would be perfect.
>
>> * How many names in each version
to below
100; I'd like to be able to keep it lower but I'm not sure we can
maintain that under all load scenarios. The compacted lists are
straightforward, but there are many ways to structure the deltas and
they all have trade offs. A CF with composite columns that supported
two dimens
imension, small_dimension). Data is queried
> based on the large dimension, and the client throws out the extra data
> in the other dimension.
>
> Neither of the above solutions are ideal. Does anyone else have a use
> case where two dimensional slicing is useful? Given the d
linear ordering
on a composite type (large_dimension, small_dimension). Data is queried
based on the large dimension, and the client throws out the extra data
in the other dimension.
Neither of the above solutions are ideal. Does anyone else have a use
case where two dimensional slicing is us
