>
> so we need to start migration from MVs to manual query base table ?

 Arguably, the other alternative to server-side denormalization is to do
the denormalization client-side which comes with the same axes of costs and
complexity, just with more of each.

Jeff's spot on when he discusses the risk appetite vs. mitigation aspect of
it. There's a reason banks do end-of-day close-out validation analysis and
have redundant systems for things like this.

On Wed, Aug 28, 2019 at 11:49 AM Jon Haddad <j...@jonhaddad.com> wrote:

> I've helped a lot of teams (a dozen to two dozen maybe) migrate away from
> MVs due to inconsistencies, issues with streaming (have you added or
> removed nodes yet?), and massive performance issues to the point of cluster
> failure under (what I consider) trivial load.  I haven't gone too deep into
> analyzing their issues, folks are usually fine with "move off them", vs
> having me do a ton of analysis.
>
> tlp-stress has a materialized view workload built in, and you can add
> arbitrary CQL via the --cql flag to add a MV to any existing workload such
> as KeyValue or BasicTimeSeries.
>
> On Wed, Aug 28, 2019 at 8:11 AM Jeff Jirsa <jji...@gmail.com> wrote:
>
> > There have been people who have had operational issues related to MVs
> (many
> > of them around running repair), but the biggest concern is correctness.
> >
> > It probably ultimately depends on what type of database you're running.
> If
> > you're running some sort of IOT / analytics workload and you just want
> > another way to SELECT the data, but you won't notice one of a billion
> > records going missing, using MVs may be fine. If you're a bank, and one
> of
> > a billion records going missing means you lose someone's bank account, I
> > would avoid using MVs.
> >
> > It's all just risk management.
> >
> > On Wed, Aug 28, 2019 at 7:18 AM Pankaj Gajjar <
> > pankaj.gaj...@contentserv.com>
> > wrote:
> >
> > > Hi Michael,
> > >
> > > Thanks for putting very clever information " Users of MVs *must*
> > determine
> > > for themselves, through
> > >     thorough testing and understanding, if they wish to use them." And
> > > this concluded that if there is any issue occur in future then only
> > > solution is to rebuild the MVs since Cassandra does not able to make
> > > consistent synch well.
> > >
> > > Also, we practically using the 10+ MVs and as of now, we have not faced
> > > any issue, so my question to all community member, does anyone face any
> > > critical issues ? so we need to start migration from MVs to manual
> query
> > > base table ?
> > >
> > > Also, I can understand now, it's experimental and not ready for
> > > production, so if possible, please ignore it only right ?
> > >
> > > Thanks
> > > Pankaj
> > >
> > > On 27/08/19, 19:03, "Michael Shuler" <mshu...@pbandjelly.org on
> behalf
> > > of mich...@pbandjelly.org> wrote:
> > >
> > >     It appears that you found the first message of the chain. I suggest
> > >     reading the linked JIRA and the complete dev@ thread that arrived
> at
> > >     this conclusion; there are loads of well formed opinions and
> > >     information. Users of MVs *must* determine for themselves, through
> > >     thorough testing and understanding, if they wish to use them.
> > >
> > >     Linkage:
> > >     https://issues.apache.org/jira/browse/CASSANDRA-13959
> > >       (sub-linkage..)
> > >       https://issues.apache.org/jira/browse/CASSANDRA-13595
> > >       https://issues.apache.org/jira/browse/CASSANDRA-13911
> > >       https://issues.apache.org/jira/browse/CASSANDRA-13880
> > >       https://issues.apache.org/jira/browse/CASSANDRA-12872
> > >       https://issues.apache.org/jira/browse/CASSANDRA-13747
> > >
> > >     Very much worth reading the complete thread:
> > >     part1:
> > >
> > >
> >
> https://lists.apache.org/thread.html/d81a61da48e1b872d7599df4edfa8e244d34cbd591a18539f724796f@
> > > <dev.cassandra.apache.org>
> > >     part2:
> > >
> > >
> >
> https://lists.apache.org/thread.html/19b7fcfd3b47f1526d6e993b3bb97f6c43e5ce204bc976ec0701cdd3@
> > > <dev.cassandra.apache.org>
> > >
> > >     Quick JQL for open tickets with "mv":
> > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20text%20~%20mv%20AND%20status%20!%3D%20Resolved
> > >
> > >     --
> > >     Michael
> > >
> > >     On 8/27/19 5:01 AM, pankaj gajjar wrote:
> > >     > Hello,
> > >     >
> > >     >
> > >     >
> > >     > concern about Materialized Views (MVs) in Cassandra.
> Unfortunately
> > > starting
> > >     > with version 3.11, MVs are officially considered experimental and
> > > not ready
> > >     > for production use, as you can read here:
> > >     >
> > >     >
> > >     >
> > >     >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/cassandra-user/201710.mbox/%3cetpan.59f24f38.438f4e99.7...@apple.com%3E
> > >     >
> > >     >
> > >     >
> > >     > Can you please someone give some productive feedback on this ? it
> > > would
> > >     > help us to further implementation around the MVs in Cassandra.
> > >     >
> > >     >
> > >     >
> > >     > Does anyone facing some critical issue or data lose or
> > > synchronization
> > >     > issue ?
> > >     >
> > >     >
> > >     >
> > >     > Regards
> > >     >
> > >     > Pankaj.
> > >     >
> > >
> > >
>  ---------------------------------------------------------------------
> > >     To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >     For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> > >
> > >
> >
>

Reply via email to