Re: Warn about SASI usage and allow to disable them
+1 on config -0 on warning -0 on disabling by default -- Jeff Jirsa > On Jan 14, 2019, at 9:22 PM, Taylor Cressy wrote: > > +1 on config. +1 on disabling. > > +1 on applying it to materialized views as well. > >> On Jan 14, 2019, at 17:29, Joshua McKenzie wrote: >> >> +1 on config change, +1 on disabling, and so long as the comments make the >> limitations and risks extremely clear, I'm fine w/out the client warning. >> >> On Mon, Jan 14, 2019 at 12:28 PM Andrés de la Peña >> wrote: >> >>> I mean disabling the creation of new SASI indices with CREATE INDEX >>> statement, the existing indexes would continue working. The CQL client >>> warning will be thrown with that creation statement as well (if they are >>> enabled). >>> On Mon, 14 Jan 2019 at 20:18, Jeff Jirsa wrote: When we say disable, do you mean disable creation of new SASI indices, or disable using existing ones? I assume it's just creation of new? On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña < a.penya.gar...@gmail.com> wrote: > Hello all, > > It is my understanding that SASI is still to be considered an > experimental/beta feature, and they apparently are not being very actively > developed. Some higlighted problems in SASI are: > > - OOMs during flush, as it is described in CASSANDRA-12662 > - General secondary index consistency problems described in CASSANDRA-8272. > There is a pending-review patch addressing the problem for regular 2i. > However, the proposed solution is based on indexing tombstones. SASI > doesn't index tombstones, so it wouldn't be enterely trivial to extend the > approach to SASI. > - Probably insufficient testing. As far as I know, we don't have a >>> single > dtest for SASI nor tests dealing with large SSTables. > > Similarly to what CASSANDRA-13959 did with materialized views, > CASSANDRA-14866 aims to throw a native protocol warning about SASI > experimental state, and to add a config property to disable them. >>> Perhaps > this property could be disabled by default in trunk. This should raise > awareness about SASI maturity until we let them in a more stable state. > > The purpose for this thread is discussing whether we want to add this > warning, the config property and, more controversially, if we want to >>> set > SASI as disabled by default in trunk. > > WDYT? > >>> > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Warn about SASI usage and allow to disable them
+1 on config. +1 on disabling. +1 on applying it to materialized views as well. > On Jan 14, 2019, at 17:29, Joshua McKenzie wrote: > > +1 on config change, +1 on disabling, and so long as the comments make the > limitations and risks extremely clear, I'm fine w/out the client warning. > > On Mon, Jan 14, 2019 at 12:28 PM Andrés de la Peña > wrote: > >> I mean disabling the creation of new SASI indices with CREATE INDEX >> statement, the existing indexes would continue working. The CQL client >> warning will be thrown with that creation statement as well (if they are >> enabled). >> >>> On Mon, 14 Jan 2019 at 20:18, Jeff Jirsa wrote: >>> >>> When we say disable, do you mean disable creation of new SASI indices, or >>> disable using existing ones? I assume it's just creation of new? >>> >>> On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña < >>> a.penya.gar...@gmail.com> >>> wrote: >>> Hello all, It is my understanding that SASI is still to be considered an experimental/beta feature, and they apparently are not being very >>> actively developed. Some higlighted problems in SASI are: - OOMs during flush, as it is described in CASSANDRA-12662 - General secondary index consistency problems described in >>> CASSANDRA-8272. There is a pending-review patch addressing the problem for regular 2i. However, the proposed solution is based on indexing tombstones. SASI doesn't index tombstones, so it wouldn't be enterely trivial to extend >>> the approach to SASI. - Probably insufficient testing. As far as I know, we don't have a >> single dtest for SASI nor tests dealing with large SSTables. Similarly to what CASSANDRA-13959 did with materialized views, CASSANDRA-14866 aims to throw a native protocol warning about SASI experimental state, and to add a config property to disable them. >> Perhaps this property could be disabled by default in trunk. This should raise awareness about SASI maturity until we let them in a more stable state. The purpose for this thread is discussing whether we want to add this warning, the config property and, more controversially, if we want to >> set SASI as disabled by default in trunk. WDYT? >>> >> - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Warn about SASI usage and allow to disable them
+1 on config change, +1 on disabling, and so long as the comments make the limitations and risks extremely clear, I'm fine w/out the client warning. On Mon, Jan 14, 2019 at 12:28 PM Andrés de la Peña wrote: > I mean disabling the creation of new SASI indices with CREATE INDEX > statement, the existing indexes would continue working. The CQL client > warning will be thrown with that creation statement as well (if they are > enabled). > > On Mon, 14 Jan 2019 at 20:18, Jeff Jirsa wrote: > > > When we say disable, do you mean disable creation of new SASI indices, or > > disable using existing ones? I assume it's just creation of new? > > > > On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña < > > a.penya.gar...@gmail.com> > > wrote: > > > > > Hello all, > > > > > > It is my understanding that SASI is still to be considered an > > > experimental/beta feature, and they apparently are not being very > > actively > > > developed. Some higlighted problems in SASI are: > > > > > > - OOMs during flush, as it is described in CASSANDRA-12662 > > > - General secondary index consistency problems described in > > CASSANDRA-8272. > > > There is a pending-review patch addressing the problem for regular 2i. > > > However, the proposed solution is based on indexing tombstones. SASI > > > doesn't index tombstones, so it wouldn't be enterely trivial to extend > > the > > > approach to SASI. > > > - Probably insufficient testing. As far as I know, we don't have a > single > > > dtest for SASI nor tests dealing with large SSTables. > > > > > > Similarly to what CASSANDRA-13959 did with materialized views, > > > CASSANDRA-14866 aims to throw a native protocol warning about SASI > > > experimental state, and to add a config property to disable them. > Perhaps > > > this property could be disabled by default in trunk. This should raise > > > awareness about SASI maturity until we let them in a more stable state. > > > > > > The purpose for this thread is discussing whether we want to add this > > > warning, the config property and, more controversially, if we want to > set > > > SASI as disabled by default in trunk. > > > > > > WDYT? > > > > > >
Re: Warn about SASI usage and allow to disable them
I mean disabling the creation of new SASI indices with CREATE INDEX statement, the existing indexes would continue working. The CQL client warning will be thrown with that creation statement as well (if they are enabled). On Mon, 14 Jan 2019 at 20:18, Jeff Jirsa wrote: > When we say disable, do you mean disable creation of new SASI indices, or > disable using existing ones? I assume it's just creation of new? > > On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña < > a.penya.gar...@gmail.com> > wrote: > > > Hello all, > > > > It is my understanding that SASI is still to be considered an > > experimental/beta feature, and they apparently are not being very > actively > > developed. Some higlighted problems in SASI are: > > > > - OOMs during flush, as it is described in CASSANDRA-12662 > > - General secondary index consistency problems described in > CASSANDRA-8272. > > There is a pending-review patch addressing the problem for regular 2i. > > However, the proposed solution is based on indexing tombstones. SASI > > doesn't index tombstones, so it wouldn't be enterely trivial to extend > the > > approach to SASI. > > - Probably insufficient testing. As far as I know, we don't have a single > > dtest for SASI nor tests dealing with large SSTables. > > > > Similarly to what CASSANDRA-13959 did with materialized views, > > CASSANDRA-14866 aims to throw a native protocol warning about SASI > > experimental state, and to add a config property to disable them. Perhaps > > this property could be disabled by default in trunk. This should raise > > awareness about SASI maturity until we let them in a more stable state. > > > > The purpose for this thread is discussing whether we want to add this > > warning, the config property and, more controversially, if we want to set > > SASI as disabled by default in trunk. > > > > WDYT? > > >
Re: Warn about SASI usage and allow to disable them
When we say disable, do you mean disable creation of new SASI indices, or disable using existing ones? I assume it's just creation of new? On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña wrote: > Hello all, > > It is my understanding that SASI is still to be considered an > experimental/beta feature, and they apparently are not being very actively > developed. Some higlighted problems in SASI are: > > - OOMs during flush, as it is described in CASSANDRA-12662 > - General secondary index consistency problems described in CASSANDRA-8272. > There is a pending-review patch addressing the problem for regular 2i. > However, the proposed solution is based on indexing tombstones. SASI > doesn't index tombstones, so it wouldn't be enterely trivial to extend the > approach to SASI. > - Probably insufficient testing. As far as I know, we don't have a single > dtest for SASI nor tests dealing with large SSTables. > > Similarly to what CASSANDRA-13959 did with materialized views, > CASSANDRA-14866 aims to throw a native protocol warning about SASI > experimental state, and to add a config property to disable them. Perhaps > this property could be disabled by default in trunk. This should raise > awareness about SASI maturity until we let them in a more stable state. > > The purpose for this thread is discussing whether we want to add this > warning, the config property and, more controversially, if we want to set > SASI as disabled by default in trunk. > > WDYT? >
Re: Warn about SASI usage and allow to disable them
I amend to +1 everything except warning, which I'm +0 on. On Mon, Jan 14, 2019 at 1:59 PM Caleb Rackliffe wrote: > +1 to config and disable > > On Mon, Jan 14, 2019, 1:54 PM Mick Semb Wever > > > > > > > The purpose for this thread is discussing whether we want to add this > > > warning, the config property and, more controversially, if we want to > set > > > SASI as disabled by default in trunk. > > > > > > I'm +1 on everything, except the warning. > > > > I think if we add the config property and it's disabled in trunk then > > we're done enough. > > Existing users should be ok. > > > > regards, > > Mick > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
Re: Warn about SASI usage and allow to disable them
+1 to config and disable On Mon, Jan 14, 2019, 1:54 PM Mick Semb Wever > > > The purpose for this thread is discussing whether we want to add this > > warning, the config property and, more controversially, if we want to set > > SASI as disabled by default in trunk. > > > I'm +1 on everything, except the warning. > > I think if we add the config property and it's disabled in trunk then > we're done enough. > Existing users should be ok. > > regards, > Mick > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Warn about SASI usage and allow to disable them
> The purpose for this thread is discussing whether we want to add this > warning, the config property and, more controversially, if we want to set > SASI as disabled by default in trunk. I'm +1 on everything, except the warning. I think if we add the config property and it's disabled in trunk then we're done enough. Existing users should be ok. regards, Mick - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Warn about SASI usage and allow to disable them
+1 to warn, config, and disable. On Mon, Jan 14, 2019 at 1:45 PM Jonathan Haddad wrote: > I'm very much in favor of a warning, and I lean towards disabling them (and > MVs, while we're at it) by default as well. > > I've seen both features be the death of clusters, and are a major risk for > teams that are brand new to Cassandra. > > > > On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña < > a.penya.gar...@gmail.com> > wrote: > > > Hello all, > > > > It is my understanding that SASI is still to be considered an > > experimental/beta feature, and they apparently are not being very > actively > > developed. Some higlighted problems in SASI are: > > > > - OOMs during flush, as it is described in CASSANDRA-12662 > > - General secondary index consistency problems described in > CASSANDRA-8272. > > There is a pending-review patch addressing the problem for regular 2i. > > However, the proposed solution is based on indexing tombstones. SASI > > doesn't index tombstones, so it wouldn't be enterely trivial to extend > the > > approach to SASI. > > - Probably insufficient testing. As far as I know, we don't have a single > > dtest for SASI nor tests dealing with large SSTables. > > > > Similarly to what CASSANDRA-13959 did with materialized views, > > CASSANDRA-14866 aims to throw a native protocol warning about SASI > > experimental state, and to add a config property to disable them. Perhaps > > this property could be disabled by default in trunk. This should raise > > awareness about SASI maturity until we let them in a more stable state. > > > > The purpose for this thread is discussing whether we want to add this > > warning, the config property and, more controversially, if we want to set > > SASI as disabled by default in trunk. > > > > WDYT? > > > > > -- > Jon Haddad > http://www.rustyrazorblade.com > twitter: rustyrazorblade >
Re: Warn about SASI usage and allow to disable them
I'm very much in favor of a warning, and I lean towards disabling them (and MVs, while we're at it) by default as well. I've seen both features be the death of clusters, and are a major risk for teams that are brand new to Cassandra. On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña wrote: > Hello all, > > It is my understanding that SASI is still to be considered an > experimental/beta feature, and they apparently are not being very actively > developed. Some higlighted problems in SASI are: > > - OOMs during flush, as it is described in CASSANDRA-12662 > - General secondary index consistency problems described in CASSANDRA-8272. > There is a pending-review patch addressing the problem for regular 2i. > However, the proposed solution is based on indexing tombstones. SASI > doesn't index tombstones, so it wouldn't be enterely trivial to extend the > approach to SASI. > - Probably insufficient testing. As far as I know, we don't have a single > dtest for SASI nor tests dealing with large SSTables. > > Similarly to what CASSANDRA-13959 did with materialized views, > CASSANDRA-14866 aims to throw a native protocol warning about SASI > experimental state, and to add a config property to disable them. Perhaps > this property could be disabled by default in trunk. This should raise > awareness about SASI maturity until we let them in a more stable state. > > The purpose for this thread is discussing whether we want to add this > warning, the config property and, more controversially, if we want to set > SASI as disabled by default in trunk. > > WDYT? > -- Jon Haddad http://www.rustyrazorblade.com twitter: rustyrazorblade
Warn about SASI usage and allow to disable them
Hello all, It is my understanding that SASI is still to be considered an experimental/beta feature, and they apparently are not being very actively developed. Some higlighted problems in SASI are: - OOMs during flush, as it is described in CASSANDRA-12662 - General secondary index consistency problems described in CASSANDRA-8272. There is a pending-review patch addressing the problem for regular 2i. However, the proposed solution is based on indexing tombstones. SASI doesn't index tombstones, so it wouldn't be enterely trivial to extend the approach to SASI. - Probably insufficient testing. As far as I know, we don't have a single dtest for SASI nor tests dealing with large SSTables. Similarly to what CASSANDRA-13959 did with materialized views, CASSANDRA-14866 aims to throw a native protocol warning about SASI experimental state, and to add a config property to disable them. Perhaps this property could be disabled by default in trunk. This should raise awareness about SASI maturity until we let them in a more stable state. The purpose for this thread is discussing whether we want to add this warning, the config property and, more controversially, if we want to set SASI as disabled by default in trunk. WDYT?
