You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Jonathan Ellis <jb...@gmail.com> on 2013/02/26 00:00:07 UTC
Notes from committer's meeting: overview
Last Thursday, DataStax put together a meeting of the active Cassandra
committers in San Mateo. Dave Brosius was unable to make it to the
West coast, but Brandon, Eric, Gary, Jason, Pavel, Sylvain, Vijay,
Yuki, and I were able to attend, with Aleksey and Jake able to attend
part time over Google Hangout.
We started by asking each committer to outline his top 3 priorities
for 2.0. There was pretty broad consensus around the following big
items, which I will break out into separate threads:
* Streaming and repair
* Counters
There was also a lot of consensus that we'll be able to ship some form
of Triggers [1] in 2.0. Gary's suggestion was to focus on getting the
functionality nailed down first, then worry about classloader voodoo
to allow live reloading. There was also general agreement that we
need to split jar loading from trigger definition, to allow a single
trigger to be applied to be multiple tables.
There was less consensus around CAS [2], primarily because of
implementation difficulties. (I've since read up some more on Paxos
and Spinnaker and posted my thoughts to the ticket.)
Other subjects discussed:
A single Cassandra process does not scale well beyond 12 physical
cores. Further research is needed to understand why. One possibility
is GC overhead. Vijay is going to test Azul's Zing VM to confirm or
refute this.
Server-side aggregation functions [3]. This would remove the need to
pull a lot of data over the wire to a client unnecessarily. There was
some unease around moving beyond the relatively simple queries we've
traditionally supported, but I think there was general agreement that
this can be addressed by fencing aggregation to a single partition
unless explicitly allowed otherwise a la ALLOW FILTERING [4].
Extending cross-datacenter forwarding [5] to a "star" model. That is,
in the case of three or more datacenters, instead of the original
coordinator in DC A sending to replicas in DC B & C, A would forward
to B, which would forward to C. Thus, the bandwidth required for any
one DC would be constant as more datacenters are added.
Vnode improvements such as a vnode-aware replication strategy [6].
Cluster merging and splitting -- if I have multiple applications using
a single cassandra cluster, and one gets a lot more traffic than the
others, I may want to split that out into its own cluster. I think
there was a concrete proposal as to how this could work but someone
else will have to fill that in because I didn't write it down.
Auto-paging of SELECT queries for CQL [7], or put another way,
transparent cursors for the native CQL driver.
Make the storage engine more CQL-aware. Low-hanging fruit here
includes a prefix dictionary for all the composite cell names [8].
Resurrecting the StorageProxy API aka Fat Client. ("Does it even work
right now?" "Not really.")
Reducing context switches and increasing fairness in client
connections. HSHA prefers to accept new connections vs servicing
existing ones, so overload situations are problematic.
"Gossip is unreliable at 100s of nodes." Here again I missed any
concrete proposals to address this.
[1] https://issues.apache.org/jira/browse/CASSANDRA-1311. Start with
https://issues.apache.org/jira/browse/CASSANDRA-1311?focusedCommentId=13492827&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13492827
for the parts relevant to Vijay's proof of concept patch.
[2] https://issues.apache.org/jira/browse/CASSANDRA-5062
[3] https://issues.apache.org/jira/browse/CASSANDRA-4914
[4] https://issues.apache.org/jira/browse/CASSANDRA-4915
[5] https://issues.apache.org/jira/browse/CASSANDRA-3577
[6] https://issues.apache.org/jira/browse/CASSANDRA-4123
[7] https://issues.apache.org/jira/browse/CASSANDRA-4415
[8] https://issues.apache.org/jira/browse/CASSANDRA-4175
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced
Re: Notes from committer's meeting: overview
Posted by Eric Evans <ee...@acunu.com>.
On Mon, Feb 25, 2013 at 5:24 PM, Anton Prakash
<an...@cloudtalk.com> wrote:
> unsubscribe
apples
> On Mon, Feb 25, 2013 at 3:23 PM, Brandon Williams <dr...@gmail.com> wrote:
>
>> On Mon, Feb 25, 2013 at 5:19 PM, Edward Capriolo <ed...@gmail.com>
>> wrote:
>> > I am curious what you mean when you say "does the fat client work right
>> > now?"
>>
>> It's not often tested.
>>
>> > What does not work about it? I have a fat client app running same jvm as
>> c*
>> > it seems to work well.
>>
>> Good to know. :)
>>
>> -Brandon
>>
--
Eric Evans
Acunu | http://www.acunu.com | @acunu
Re: Notes from committer's meeting: overview
Posted by Michael Kjellman <mk...@barracuda.com>.
https://www.google.com
On 2/25/13 3:24 PM, "Anton Prakash" <an...@cloudtalk.com> wrote:
>unsubscribe
>
>
>On Mon, Feb 25, 2013 at 3:23 PM, Brandon Williams <dr...@gmail.com>
>wrote:
>
>> On Mon, Feb 25, 2013 at 5:19 PM, Edward Capriolo <ed...@gmail.com>
>> wrote:
>> > I am curious what you mean when you say "does the fat client work
>>right
>> > now?"
>>
>> It's not often tested.
>>
>> > What does not work about it? I have a fat client app running same jvm
>>as
>> c*
>> > it seems to work well.
>>
>> Good to know. :)
>>
>> -Brandon
>>
Copy, by Barracuda, helps you store, protect, and share all your amazing
things. Start today: www.copy.com.
Re: Notes from committer's meeting: overview
Posted by Anton Prakash <an...@cloudtalk.com>.
unsubscribe
On Mon, Feb 25, 2013 at 3:23 PM, Brandon Williams <dr...@gmail.com> wrote:
> On Mon, Feb 25, 2013 at 5:19 PM, Edward Capriolo <ed...@gmail.com>
> wrote:
> > I am curious what you mean when you say "does the fat client work right
> > now?"
>
> It's not often tested.
>
> > What does not work about it? I have a fat client app running same jvm as
> c*
> > it seems to work well.
>
> Good to know. :)
>
> -Brandon
>
Re: Notes from committer's meeting: overview
Posted by Brandon Williams <dr...@gmail.com>.
On Mon, Feb 25, 2013 at 5:19 PM, Edward Capriolo <ed...@gmail.com> wrote:
> I am curious what you mean when you say "does the fat client work right
> now?"
It's not often tested.
> What does not work about it? I have a fat client app running same jvm as c*
> it seems to work well.
Good to know. :)
-Brandon
Re: Notes from committer's meeting: overview
Posted by Edward Capriolo <ed...@gmail.com>.
I am curious what you mean when you say "does the fat client work right
now?"
What does not work about it? I have a fat client app running same jvm as c*
it seems to work well.
On Monday, February 25, 2013, Jonathan Ellis <jb...@gmail.com> wrote:
> Last Thursday, DataStax put together a meeting of the active Cassandra
> committers in San Mateo. Dave Brosius was unable to make it to the
> West coast, but Brandon, Eric, Gary, Jason, Pavel, Sylvain, Vijay,
> Yuki, and I were able to attend, with Aleksey and Jake able to attend
> part time over Google Hangout.
>
> We started by asking each committer to outline his top 3 priorities
> for 2.0. There was pretty broad consensus around the following big
> items, which I will break out into separate threads:
>
> * Streaming and repair
> * Counters
>
> There was also a lot of consensus that we'll be able to ship some form
> of Triggers [1] in 2.0. Gary's suggestion was to focus on getting the
> functionality nailed down first, then worry about classloader voodoo
> to allow live reloading. There was also general agreement that we
> need to split jar loading from trigger definition, to allow a single
> trigger to be applied to be multiple tables.
>
> There was less consensus around CAS [2], primarily because of
> implementation difficulties. (I've since read up some more on Paxos
> and Spinnaker and posted my thoughts to the ticket.)
>
> Other subjects discussed:
>
> A single Cassandra process does not scale well beyond 12 physical
> cores. Further research is needed to understand why. One possibility
> is GC overhead. Vijay is going to test Azul's Zing VM to confirm or
> refute this.
>
> Server-side aggregation functions [3]. This would remove the need to
> pull a lot of data over the wire to a client unnecessarily. There was
> some unease around moving beyond the relatively simple queries we've
> traditionally supported, but I think there was general agreement that
> this can be addressed by fencing aggregation to a single partition
> unless explicitly allowed otherwise a la ALLOW FILTERING [4].
>
> Extending cross-datacenter forwarding [5] to a "star" model. That is,
> in the case of three or more datacenters, instead of the original
> coordinator in DC A sending to replicas in DC B & C, A would forward
> to B, which would forward to C. Thus, the bandwidth required for any
> one DC would be constant as more datacenters are added.
>
> Vnode improvements such as a vnode-aware replication strategy [6].
>
> Cluster merging and splitting -- if I have multiple applications using
> a single cassandra cluster, and one gets a lot more traffic than the
> others, I may want to split that out into its own cluster. I think
> there was a concrete proposal as to how this could work but someone
> else will have to fill that in because I didn't write it down.
>
> Auto-paging of SELECT queries for CQL [7], or put another way,
> transparent cursors for the native CQL driver.
>
> Make the storage engine more CQL-aware. Low-hanging fruit here
> includes a prefix dictionary for all the composite cell names [8].
>
> Resurrecting the StorageProxy API aka Fat Client. ("Does it even work
> right now?" "Not really.")
>
> Reducing context switches and increasing fairness in client
> connections. HSHA prefers to accept new connections vs servicing
> existing ones, so overload situations are problematic.
>
> "Gossip is unreliable at 100s of nodes." Here again I missed any
> concrete proposals to address this.
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-1311. Start with
>
https://issues.apache.org/jira/browse/CASSANDRA-1311?focusedCommentId=13492827&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13492827
> for the parts relevant to Vijay's proof of concept patch.
> [2] https://issues.apache.org/jira/browse/CASSANDRA-5062
> [3] https://issues.apache.org/jira/browse/CASSANDRA-4914
> [4] https://issues.apache.org/jira/browse/CASSANDRA-4915
> [5] https://issues.apache.org/jira/browse/CASSANDRA-3577
> [6] https://issues.apache.org/jira/browse/CASSANDRA-4123
> [7] https://issues.apache.org/jira/browse/CASSANDRA-4415
> [8] https://issues.apache.org/jira/browse/CASSANDRA-4175
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>