No, there will be deletes and inserts in the middle. But I can assume that
the index will only grow. There will be few deletes.
On Tue, Jun 8, 2010 at 7:04 PM, Tatu Saloranta wrote:
> On Tue, Jun 8, 2010 at 1:28 AM, David Boxenhorn wrote:
> > As I said above, I was wondering if I could come up
On Tue, Jun 8, 2010 at 1:28 AM, David Boxenhorn wrote:
> As I said above, I was wondering if I could come up with a robust algorithm,
> e.g. creating the new super columns and then attaching them at the end,
> which will not FUBAR my index if it fails.
>
Is this append-only? That is, never delete
As I said above, I was wondering if I could come up with a robust algorithm,
e.g. creating the new super columns and then attaching them at the end,
which will not FUBAR my index if it fails.
On Tue, Jun 8, 2010 at 10:53 AM, Tatu Saloranta wrote:
> On Tue, Jun 8, 2010 at 12:07 AM, David Boxenhorn
On Tue, Jun 8, 2010 at 12:07 AM, David Boxenhorn wrote:
> I am not worried about getting the occasional wrong result - if I were, I
> couldn't use Cassandra. I am only worried about breaking the index as a
> whole. If concurrent changes to the tree happen to modify the same record, I
> don't mind
I am not worried about getting the occasional wrong result - if I were, I
couldn't use Cassandra. I am only worried about breaking the index as a
whole. If concurrent changes to the tree happen to modify the same record, I
don't mind if one of them "wins" as long as the result is a working tree.
O
On Mon, Jun 7, 2010 at 3:09 PM, Ian Soboroff wrote:
> I was going to say, if ordered trees are your problem, Cassandra is not your
> solution. Try building something with Berkeley DB.
Also -- while there are no official plans for this, there have been
discussions on Voldemort list, wrt. possible
I was going to say, if ordered trees are your problem, Cassandra is
not your solution. Try building something with Berkeley DB.
Ian
On Jun 7, 2010, at 17:30, Tatu Saloranta wrote:
On Mon, Jun 7, 2010 at 12:06 AM, David Boxenhorn
wrote:
I wonder if there is a robust algorithm for maintain
On Mon, Jun 7, 2010 at 12:06 AM, David Boxenhorn wrote:
> I wonder if there is a robust algorithm for maintaining b-trees that doesn't
> require atomicity? How about if you create the three new super columns
> first, then attach them to the parent, then delete the old super column? If
> it fails,
I wonder if there is a robust algorithm for maintaining b-trees that doesn't
require atomicity? How about if you create the three new super columns
first, then attach them to the parent, then delete the old super column? If
it fails, it would leave junk, but that could be cleaned up every once in a
Quote from Gary:
batch_mutate makes no atomicity guarantees. It s intended to help avoiding
many round-trips.
It can fail half-way through leaving you with a partially completed batch.
On Mon, Jun 7, 2010 at 9:39 AM, David Boxenhorn wrote:
> Is batch mutate atomic? If not, can we make it so?
>
Is batch mutate atomic? If not, can we make it so?
On Mon, Jun 7, 2010 at 4:11 AM, Tatu Saloranta wrote:
> Yeah, or maybe just "clustering", since there is no branching structure.
> It's quite commonly useful even on regular b-tree style storage (BDB
> et al), as it can reduce per-entry overhead
Yeah, or maybe just "clustering", since there is no branching structure.
It's quite commonly useful even on regular b-tree style storage (BDB
et al), as it can reduce per-entry overhead quite a bit. And allows
very efficient compression, if entries have lots of redundancy (xml or
json serialized da
sounds interesting... btree on top of cassandra ;)
On Sun, Jun 6, 2010 at 12:16 PM, David Boxenhorn wrote:
> I'm still thinking about the problem of how to handle range queries on very
> large sets of data, using Random Partitioning.
>
> Has anyone used tree search to solve this? What do you thi
I'm still thinking about the problem of how to handle range queries on very
large sets of data, using Random Partitioning.
Has anyone used tree search to solve this? What do you think?
More specifically, something like this:
- Store a maximum of 1000 values per supercolumn (or some other fixed
n
14 matches
Mail list logo
