See my blog post to understand how MV is implemented: http://www.doanduyhai.com/blog/?p=1930
On Fri, Feb 10, 2017 at 7:48 PM, Benjamin Roth <benjamin.r...@jaumo.com> wrote: > Same partition key: > > PRIMARY KEY ((a, b), c, d) and > PRIMARY KEY ((a, b), d, c) > > PRIMARY KEY ((a), b, c) and > PRIMARY KEY ((a), c, b) > > Different partition key: > > PRIMARY KEY ((a, b), c, d) and > PRIMARY KEY ((a), b, d, c) > > PRIMARY KEY ((a), b) and > PRIMARY KEY ((b), a) > > > 2017-02-10 19:46 GMT+01:00 Kant Kodali <k...@peernova.com>: > > > Okies now I understand what you mean by "same" partition key. I think > you > > are saying > > > > PRIMARY KEY(col1, col2, col3) == PRIMARY KEY(col2, col1, col3) // so far > I > > assumed they are different partition keys. > > > > On Fri, Feb 10, 2017 at 10:36 AM, Benjamin Roth <benjamin.r...@jaumo.com > > > > wrote: > > > > > There are use cases where the partition key is the same. For example if > > you > > > need a sorting within a partition or a filtering different from the > > > original clustering keys. > > > We actually use this for some MVs. > > > > > > If you want "dumb" denormalization with simple append only cases (or > more > > > general cases that don't require a read before write on update) you are > > > maybe better off with batched denormalized atomics writes. > > > > > > The main benefit of MVs is if you need denormalization to sort or > filter > > by > > > a non-primary key field. > > > > > > 2017-02-10 19:31 GMT+01:00 Kant Kodali <k...@peernova.com>: > > > > > > > yes thanks for the clarification. But why would I ever have MV with > > the > > > > same partition key? if it is the same partition key I could just read > > > from > > > > the base table right? our MV Partition key contains the columns from > > the > > > > base table partition key but in a different order plus an additional > > > column > > > > (which is allowed as of today) > > > > > > > > On Fri, Feb 10, 2017 at 10:23 AM, Benjamin Roth < > > benjamin.r...@jaumo.com > > > > > > > > wrote: > > > > > > > > > It depends on your model. > > > > > If the base table + MV have the same partition key, then the MV > > > mutations > > > > > are applied synchronously, so they are written as soon the write > > > request > > > > > returns. > > > > > => In this case you can rely on the R+F > RF > > > > > > > > > > If the partition key of the MV is different, the partition of the > MV > > is > > > > > probably placed on a different host (or said differently it cannot > be > > > > > guaranteed that it is on the same host). In this case, the MV > updates > > > are > > > > > executed async in a logged batch. So it can be guaranteed they will > > be > > > > > applied eventually but not at the time the write request returns. > > > > > => You cannot rely and there is no possibility to absolutely > > guarantee > > > > > anything, not matter what CL you choose. A MV update may always > > "arrive > > > > > late". I guess it has been implemented like this to not block in > case > > > of > > > > > remote request to prefer the cluster sanity over consistency. > > > > > > > > > > Is it now 100% clear? > > > > > > > > > > 2017-02-10 19:17 GMT+01:00 Kant Kodali <k...@peernova.com>: > > > > > > > > > > > So R+W > RF doesnt apply for reads on MV right because say I set > > > QUORUM > > > > > > level consistency for both reads and writes then there can be a > > > > scenario > > > > > > where a write is successful to the base table and then say > > > immediately > > > > I > > > > > do > > > > > > a read through MV but prior to MV getting the update from the > base > > > > table. > > > > > > so there isn't any way to make sure to read after MV had been > > > > > successfully > > > > > > updated. is that correct? > > > > > > > > > > > > On Fri, Feb 10, 2017 at 6:30 AM, Benjamin Roth < > > > > benjamin.r...@jaumo.com> > > > > > > wrote: > > > > > > > > > > > > > Hi Kant > > > > > > > > > > > > > > Is it clear now? > > > > > > > Sorry for the confusion! > > > > > > > > > > > > > > Have a nice one > > > > > > > > > > > > > > Am 10.02.2017 09:17 schrieb "Kant Kodali" <k...@peernova.com>: > > > > > > > > > > > > > > thanks! > > > > > > > > > > > > > > On Thu, Feb 9, 2017 at 8:51 PM, Benjamin Roth < > > > > benjamin.r...@jaumo.com > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Yes it is > > > > > > > > > > > > > > > > Am 10.02.2017 00:46 schrieb "Kant Kodali" <k...@peernova.com > >: > > > > > > > > > > > > > > > > > If reading from materialized view with a consistency level > of > > > > > quorum > > > > > > am > > > > > > > I > > > > > > > > > guaranteed to have the most recent view? other words is w > + r > > > > n > > > > > > > > contract > > > > > > > > > maintained for MV's as well for both reads and writes? > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Benjamin Roth > > > > > Prokurist > > > > > > > > > > Jaumo GmbH · www.jaumo.com > > > > > Wehrstraße 46 · 73035 Göppingen · Germany > > > > > Phone +49 7161 304880-6 · Fax +49 7161 304880-1 > > > > > AG Ulm · HRB 731058 · Managing Director: Jens Kammerer > > > > > > > > > > > > > > > > > > > > > -- > > > Benjamin Roth > > > Prokurist > > > > > > Jaumo GmbH · www.jaumo.com > > > Wehrstraße 46 · 73035 Göppingen · Germany > > > Phone +49 7161 304880-6 · Fax +49 7161 304880-1 > > > AG Ulm · HRB 731058 · Managing Director: Jens Kammerer > > > > > > > > > -- > Benjamin Roth > Prokurist > > Jaumo GmbH · www.jaumo.com > Wehrstraße 46 · 73035 Göppingen · Germany > Phone +49 7161 304880-6 · Fax +49 7161 304880-1 > AG Ulm · HRB 731058 · Managing Director: Jens Kammerer >
