I fully agree to Jon here. We previously also used MV’s and major problems popped up on decommissioning/commissioning nodes. After replacing them by doing the MV’s job “manually” by code, we did not face those issues anymore.
Regards, Christian Von: Jon Haddad <j...@jonhaddad.com> Antworten an: "user@cassandra.apache.org" <user@cassandra.apache.org> Datum: Donnerstag, 25. Juli 2019 um 23:53 An: "user@cassandra.apache.org" <user@cassandra.apache.org> Betreff: Re: Materialized View's additional PrimaryKey column The issues I have with MVs aren't related to how they aren't correctly synchronized, although I'm not happy about that either. My issue with them are in every cluster I've seen that uses them, the cluster has been unstable, and I've put a lot of time into helping teams undo them. You will almost certainly have several hours or days of downtime as a result of using them. There's a good reason they're marked as experimental (and disabled by default). You should maintain the other tables yourself. Jon On Thu, Jul 25, 2019 at 12:22 AM mehmet bursali <bursal...@yahoo.com.invalid> wrote: Hi Jon, thanks for your suggestion (or warning :) ). yes, i've read sth. about your point and i know that just because of using MVs, there are really several issues open in JIRA on bootstrapping, compaction and incremental repair stuff but, after reading almost all jira tickets (with comments and history) related to using MVs, AFAU all that issues come out by either loosing syncronization between base table and MV by deleting columns or rows values on base table or having a huge system that has large and dynamic number of nodes/data/workloads. We use 3.11.3 version and most of the critical issues were fixed on 3.10 but of course I might be miss sth so i 'll be glad if you point me some specific jira ticket. We have a certain use case that require updates on filtering (clustering) columns.Our motivation for using MV was avoiding updates (delete + create) on primaryKey columns because we suppose that cassandra developers can manage this unpreferred operation better then us. I'm really confused now. On Wednesday, July 24, 2019, 11:30:15 PM GMT+3, Jon Haddad <j...@jonhaddad.com<mailto:j...@jonhaddad.com>> wrote: I really, really advise against using MVs. I've had to help a number of teams move off them. Not sure what list of bugs you read, but if the list didn't include "will destabilize your cluster to the point of constant downtime" then the list was incomplete. Jon On Wed, Jul 24, 2019 at 6:32 AM mehmet bursali <bursal...@yahoo.com.invalid> wrote: + additional info: our production environment is a multiDC cluster that consist of 6 nodes in 2 DataCenters On Wednesday, July 24, 2019, 3:35:11 PM GMT+3, mehmet bursali <bursal...@yahoo.com.INVALID> wrote: Hi Cassandra folks, I'm planning to use Materialized View (MV) on production for some specific cases. I've read a lot of blogs, technical documents about the risks of using it and everything seems ok for our use case. My question is about consistency(also durability) evaluation of MV usage with an additional primary key column. İn one of our case, we select an UDT column of base table as addtional primary key column on MV. (UDT possible values are non nullable and restricted with domain.) . After inserting a record in base table, this additonal column (MVs primary key column) value also will be updated for 1 or 2 time. So in our case, for each update operation that will be occured on base table there are going to be delete and create operations inside MV. Does it matter from consistency(also durability) perspective that using additional primary key column whether as partition column or clustering column?
