, September 3, 2019 5:47 AM
To: dev@cassandra.apache.org
Subject: Re: Stability of MaterializedView in 3.11.x | 4.0
Hi Team,
Thanks but this is not point, question again in mind, do we have any plan to
fix this MVs issue into upcoming any Cassandra release ? 4.0 ? if yes then it
would be great to wait
Hi Team,
Thanks but this is not point, question again in mind, do we have any plan to
fix this MVs issue into upcoming any Cassandra release ? 4.0 ? if yes then it
would be great to wait.
Or is there any plugin or workaround to resolve this issue well on Cassandra
setup ?
--
Regards
Pankaj
If you don't have any intent on running across multiple nodes, Cassandra is
probably the wrong DB for you.
Postgres will give you a better feature set for a single node.
On Fri, Aug 30, 2019 at 5:23 AM Pankaj Gajjar
wrote:
> Understand it well, how about Cassandra running on single node, we
Single node indeed doesn't need repair so it's easier.
There is an admission control issue with MVs since they can incur a huge
amplification, a single change in the base can trigger
1000s of operations in the view and they run async*. Hinted handoff for
the MV helps as well but isn't needed for
Understand it well, how about Cassandra running on single node, we don’t have
cluster setup (3 nodes+ i.e).
Does MVs perform well on single node machine ?
Note: I know about HA, so lets keep it side for now and it's only possible when
we have cluster setup.
On 29/08/19, 06:21, "Dor Laor"
On Wed, Aug 28, 2019 at 5:43 PM Jon Haddad wrote:
> > 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.
>
> That's not completely true. You can write to any
> 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.
That's not completely true. You can write to any number of tables without
doing a read, and the cost of
>
> 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
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
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
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
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
Hi Pankaj,
The main issues are described in the link you posted and are some
synchronization issues
* There's no way to determine if a view is out of sync with the base table.
* If you do determine that a view is out of sync, the only way to fix
it is to drop and rebuild
the view.
Even in the
13 matches
Mail list logo
