cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2893) Add row-level isolation
Date Thu, 22 Dec 2011 18:19:31 GMT


Sylvain Lebresne commented on CASSANDRA-2893:

bq. should we just get rid of AbstractColumnContainer now since it's basically just a wrapper
around ISortedColumns?

It's still useful to factor the code between ColumnFamily and SuperColumn. If we remove it,
we'll basically have to duplicate ACC into both CF and SC. But I'll be more than happy to
remove it when/if we remove SCs :P

bq. Doesn't Guava Functions.identity do the same as ACC.identity?

Totally, I guess I don't know Guava too well. I'll replace it.

bq. I wonder if this is premature optimization or even counterproductive for the uncontended
case. Did you do any testing around this?

To be honest, I did not test it. But the rational is that I would be surprised if checking
an atomic ref get (even on each iteration) has any kind of visible impact (compared to adding
a column to a snaptree), while I have no doubt that in the contended case with non trivially
small batches not doing this will have a visible impact. That was more about trading a probably
non-noticeable hit on non-contended to avoid any bad outliers.

I also though about doing the the reference check only every few iterations, but I figured
that would likely don't change anything since again an atomic ref get should be really fast.

But obviously it doesn't cost much to check those assumptions and I'll do some testing.

I'll also note that we could easily change snaptree by a persistent sorted map. This could
be faster than snaptree because there would be any internal synchronization (while snaptree
has internal synchronization, that we mostly don't use, except for the fact that they allow
a concurrently safe copy-on-write). I have a persistent store map implementation almost ready
so I'll probably do that test at some point, but if we think snaptree is acceptable I suggest
we go with that at first since it is absolutely unclear the persistent sorted map will be
faster (it will generate more garbage for instance) and I'm sure how long it will take to
do such a test.
> Add row-level isolation
> -----------------------
>                 Key: CASSANDRA-2893
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jonathan Ellis
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 1.1
>         Attachments: 0001-Move-deletion-infos-into-ISortedColumns-v2.patch, 0001-Move-deletion-infos-into-ISortedColumns.patch,
0002-Make-memtable-use-CF.addAll-v2.patch, 0002-Make-memtable-use-CF.addAll.patch, 0003-Add-AtomicSortedColumn-and-snapTree-v2.patch,
0003-Add-AtomicSortedColumn-and-snapTree.patch, latency-plain.svg, latency.svg, snaptree-0.1-SNAPSHOT.jar
> This could be done using an the atomic ConcurrentMap operations from the Memtable and
something like to replace the ConcurrentSkipListMap
in ThreadSafeSortedColumns.  The trick is that pcollections does not provide a SortedMap,
so we probably need to write our own.
> Googling [persistent sortedmap] I found
(in scala) and Structures-Maps.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message