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
Thanks for the reminder :) I have a few days of availability to prep a
4.0 alpha release. It's an alpha, so I don't have a problem with known
issues needing work.
I will have an internet-less period of time starting roughly Tuesday 9/3
through about Friday 9/13. I might get lucky and have a li
Yes we do. It's one of the reasons I've spent about a lot of (thousands?)
hours working on tlp-stress and tlp-cluster in the last 2 years. I shared
some progress on this a little ways back. I'll send out a separate email
soon with updates, since we just merged in a *lot* of features that will
he
+1 on cutting an alpha and having a clear, documented test plan[1] for alpha.
We need volunteers to drive the test plan, though. :)
Thanks,
Dinesh
[1]
https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans
> On Aug 28, 2019, at 10:27 AM, Jon Haddad wro
> 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 readin
Regarding the dynamic snitch improvements, it's gone through several rounds
of review already and there's been significant testing of it. Regarding
the token change, switching a number from 256 -> 16 isn't so invasive that
we shouldn't do it. There's a little extra work that needs to be done
ther
>
> 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 ris
>
> dynamic snitch improvements, fixing token counts
> they're small enough
By what axis of measurement out of curiosity? Risk to re-test and validate
a final artifact? Do we have a more clear understanding of what testing has
taken place across the community?
The last I saw, our documented t
Hey folks,
I think it's time we cut a 4.0 alpha release. Before I put up a vote
thread, is there a reason not to have a 4.0 alpha before ApacheCon /
Cassandra Summit?
There's a handful of small issues that I should be done for 4.0 (client
list in virtual tables, dynamic snitch improvements, fixi
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
anal
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
anot
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 Cassand
12 matches
Mail list logo
