Re: Cassandra on RocksDB experiment result

[Dikang Gu]

@Samba, that's a very good point, I definitely do not expect all storage
engines provide exactly same features, and each storage engine should have
it's own strength and sweet spots as well. For features not supported by
certain storage engine, I think it should throw exceptions and fail the
requests. It will be better than swallowing the errors silently.

On Wed, Apr 26, 2017 at 7:40 AM, Samba  wrote:

> some features may work with some storage engine but with others; for
> example, storing large blobs may be efficient in one storage engine while
> quite worse in another. perhaps some storage engines may want to SKIP some
> features or add more.
>
> if a storage engine skips a feature, how should the query executor handle
> the response or lack of it?
> if a storage engine provides a new feature, how should that be enabled for
> that particular storage engine alone?
>
> On Wed, Apr 26, 2017 at 5:07 AM, Dikang Gu  wrote:
>
> > I created several tickets to start the discussion, please free feel to
> > comment on the JIRAs. I'm also open for suggestions about other efficient
> > ways to discuss it.
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-13474
> > https://issues.apache.org/jira/browse/CASSANDRA-13475
> > https://issues.apache.org/jira/browse/CASSANDRA-13476
> >
> > Thanks
> > Dikang.
> >
> > On Mon, Apr 24, 2017 at 9:53 PM, Dikang Gu  wrote:
> >
> > > 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
> > >
> > >
> >
> >
> > --
> > Dikang
> >
>



-- 
Dikang

Re: Way to unsubscribe from mailing lists

[Jake Luciani]

Another option would be to add a unsubscribe header, not sure if we already
do but I think that causes gmail/outlook to add a unsubscribe button

http://www.list-unsubscribe.com/

On Wed, Apr 26, 2017 at 11:24 AM, Eric Evans 
wrote:

> On Wed, Apr 26, 2017 at 9:36 AM, Jake Farrell  wrote:
> > moderators can also subscribe/unsubscribe people by sending an email
> using
> > the following pattern
> >
> > example to unsubscribe u...@example.com:
> > dev-unsubscribe-user=example@cassandra.apache.org
>
> Doing so seem prone to abuse though.
>
>
> --
> Eric Evans
> john.eric.ev...@gmail.com
>



-- 
http://twitter.com/tjake

Re: Way to unsubscribe from mailing lists

[Eric Evans]

On Wed, Apr 26, 2017 at 9:36 AM, Jake Farrell  wrote:
> moderators can also subscribe/unsubscribe people by sending an email using
> the following pattern
>
> example to unsubscribe u...@example.com:
> dev-unsubscribe-user=example@cassandra.apache.org

Doing so seem prone to abuse though.


-- 
Eric Evans
john.eric.ev...@gmail.com

Re: Way to unsubscribe from mailing lists

[Michael Shuler]

On 04/26/2017 07:51 AM, Nate McCall wrote:
> I'm fine with that footer. I see that from other lists I'm on and it
> doesn't bother me.

https://issues.apache.org/jira/browse/INFRA-14017 request made.

-- 
Michael

Re: Cassandra on RocksDB experiment result

[Samba]

some features may work with some storage engine but with others; for
example, storing large blobs may be efficient in one storage engine while
quite worse in another. perhaps some storage engines may want to SKIP some
features or add more.

if a storage engine skips a feature, how should the query executor handle
the response or lack of it?
if a storage engine provides a new feature, how should that be enabled for
that particular storage engine alone?

On Wed, Apr 26, 2017 at 5:07 AM, Dikang Gu  wrote:

> I created several tickets to start the discussion, please free feel to
> comment on the JIRAs. I'm also open for suggestions about other efficient
> ways to discuss it.
>
> https://issues.apache.org/jira/browse/CASSANDRA-13474
> https://issues.apache.org/jira/browse/CASSANDRA-13475
> https://issues.apache.org/jira/browse/CASSANDRA-13476
>
> Thanks
> Dikang.
>
> On Mon, Apr 24, 2017 at 9:53 PM, Dikang Gu  wrote:
>
> > 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
> >
> >
>
>
> --
> Dikang
>

Re: Way to unsubscribe from mailing lists

[Jake Farrell]

moderators can also subscribe/unsubscribe people by sending an email using
the following pattern

example to unsubscribe u...@example.com:
dev-unsubscribe-user=example@cassandra.apache.org

-Jake


On Wed, Apr 26, 2017 at 8:51 AM, Nate McCall  wrote:

> > Is anyone opposed to including a footer on all the
> > *@cassandra.apache.org lists? I think this could be helpful.
> >
> > I've appended a default-ish ezmlm "trailer text" that I found in a doc.
> >
> > --
> > Kind regards,
> > Michael
> >
> > ---
> >  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >  For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
>
> I'm fine with that footer. I see that from other lists I'm on and it
> doesn't bother me.
>

Re: Way to unsubscribe from mailing lists

[Nate McCall]

> Is anyone opposed to including a footer on all the
> *@cassandra.apache.org lists? I think this could be helpful.
>
> I've appended a default-ish ezmlm "trailer text" that I found in a doc.
>
> --
> Kind regards,
> Michael
>
> ---
>  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>  For additional commands, e-mail: dev-h...@cassandra.apache.org



I'm fine with that footer. I see that from other lists I'm on and it
doesn't bother me.