Re: Cassandra on RocksDB experiment result

2017-04-24 Thread Nate McCall
> Please take a look and let me know your thoughts. I think the biggest
> latency win comes from we get rid of most Java garbages created by current
> read/write path and compactions, which reduces the JVM overhead and makes
> the latency to be more predictable.
>

I want to put this here for the record:
https://issues.apache.org/jira/browse/CASSANDRA-2995

There are some valid points in the above about increased surface area
and end-user confusion. That said, just under six years is a long
time. I think we are a more mature project now and I completely agree
with others about the positive impacts of testability this would
inherently provide.

+1 from me.

Dikang, thank you for opening this discussion and sharing your efforts so far.


Re: unsubscribe

2017-04-24 Thread LuckyBoy
unsubscribe

On Wed, Apr 5, 2017 at 1:35 AM, 郑蒙家(蒙家) 
wrote:

> unsubscribe


Re: Cassandra on RocksDB experiment result

2017-04-24 Thread LuckyBoy
unsubscribe

On Sun, Apr 23, 2017 at 4:25 PM, Nate McCall  wrote:

> > Please take a look and let me know your thoughts. I think the biggest
> > latency win comes from we get rid of most Java garbages created by
> current
> > read/write path and compactions, which reduces the JVM overhead and makes
> > the latency to be more predictable.
> >
>
> I want to put this here for the record:
> https://issues.apache.org/jira/browse/CASSANDRA-2995
>
> There are some valid points in the above about increased surface area
> and end-user confusion. That said, just under six years is a long
> time. I think we are a more mature project now and I completely agree
> with others about the positive impacts of testability this would
> inherently provide.
>
> +1 from me.
>
> Dikang, thank you for opening this discussion and sharing your efforts so
> far.
>


Guidelines on testing

2017-04-24 Thread Blake Eggleston
About a month ago, in the ‘Code quality, principles and rules’ thread, I’d 
proposed adding some testing standards to the project in lieu of revisiting the 
idea of removing singletons. The idea was that we could drive incremental 
improvement of the test coverage and testability situation that could be 
applied in day to day work. I’ve pushed a first draft to my repo here:

https://github.com/bdeggleston/cassandra/blob/testing-doc/TESTING.md

Please take a look and let me know what you think. With the blessing of the 
pmc, I’d like this, or something like it, to be adopted as the reference for 
contributors and reviewers when deciding if a contribution is properly tested.

Blake


Re: Cassandra on RocksDB experiment result

2017-04-24 Thread Patrick McFadin
Dikang,

First I want to thank you and everyone else at Instragram for the
engineering talent you have devoted to the Cassandra project. Here's yet
another great example.

He's going to hate me for dragging him into this, but Vijay Parthasarathy
has done some exploratory work before on integrating non-java storage to
Cassandra. Might be helpful person to consult.

Patrick



On Sun, Apr 23, 2017 at 4:25 PM, Nate McCall  wrote:

> > Please take a look and let me know your thoughts. I think the biggest
> > latency win comes from we get rid of most Java garbages created by
> current
> > read/write path and compactions, which reduces the JVM overhead and makes
> > the latency to be more predictable.
> >
>
> I want to put this here for the record:
> https://issues.apache.org/jira/browse/CASSANDRA-2995
>
> There are some valid points in the above about increased surface area
> and end-user confusion. That said, just under six years is a long
> time. I think we are a more mature project now and I completely agree
> with others about the positive impacts of testability this would
> inherently provide.
>
> +1 from me.
>
> Dikang, thank you for opening this discussion and sharing your efforts so
> far.
>


Re: Cassandra on RocksDB experiment result

2017-04-24 Thread Dikang Gu
Thanks everyone for the feedback and suggestions! They are all very
helpful. I'm looking forward to having more discussions about the
implementation details.

As the next step, we will be focus on three areas:
1. Pluggable storage engine interface.
2. Wide column support on RocksDB.
3. Streaming support on RocksDB.

I will go ahead and create some JIRAs, to start the discussion about
pluggable storage interface, and how to plug RocksDB into Cassandra.

Please let me know your thoughts.

Thanks!
Dikang.

On Mon, Apr 24, 2017 at 12:42 PM, Patrick McFadin 
wrote:

> Dikang,
>
> First I want to thank you and everyone else at Instragram for the
> engineering talent you have devoted to the Cassandra project. Here's yet
> another great example.
>
> He's going to hate me for dragging him into this, but Vijay Parthasarathy
> has done some exploratory work before on integrating non-java storage to
> Cassandra. Might be helpful person to consult.
>
> Patrick
>
>
>
> On Sun, Apr 23, 2017 at 4:25 PM, Nate McCall  wrote:
>
> > > Please take a look and let me know your thoughts. I think the biggest
> > > latency win comes from we get rid of most Java garbages created by
> > current
> > > read/write path and compactions, which reduces the JVM overhead and
> makes
> > > the latency to be more predictable.
> > >
> >
> > I want to put this here for the record:
> > https://issues.apache.org/jira/browse/CASSANDRA-2995
> >
> > There are some valid points in the above about increased surface area
> > and end-user confusion. That said, just under six years is a long
> > time. I think we are a more mature project now and I completely agree
> > with others about the positive impacts of testability this would
> > inherently provide.
> >
> > +1 from me.
> >
> > Dikang, thank you for opening this discussion and sharing your efforts so
> > far.
> >
>



-- 
Dikang