If you want to test the scenarios thia project would be helpful Http://github.com/edwardcapriolo/ec
I use brute force at different CL and assert if i detect and consistency issues. Having mvs would be nice On Saturday, February 11, 2017, Benjamin Roth <benjamin.r...@jaumo.com> wrote: > For MVs regarding this threads question only the partition key matters. > Different primary keys can have the same partition key. Which is the case > in the example in your last comment. > > Am 10.02.2017 20:26 schrieb "Kant Kodali" <k...@peernova.com > <javascript:;>>: > > @Benjamin Roth: How do you say something is a different PRIMARY KEY now? > looks like you are saying > > The below is same partition key and same primary key? > > PRIMARY KEY ((a, b), c, d) and > PRIMARY KEY ((a, b), d, c) > > @Russell Great to see you here! As always that is spot on! > > On Fri, Feb 10, 2017 at 11:13 AM, Benjamin Roth <benjamin.r...@jaumo.com > <javascript:;>> > wrote: > > > Thanks a lot for that post. If I read the code right, then there is one > > case missing in your post. > > According to StorageProxy.mutateMV, local updates are NOT put into a > batch > > and are instantly applied locally. So a batch is only created if remote > > mutations have to be applied and only for those mutations. > > > > 2017-02-10 19:58 GMT+01:00 DuyHai Doan <doanduy...@gmail.com > <javascript:;>>: > > > > > 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 <javascript:;>> > > > 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 > <javascript:;>>: > > > > > > > > > 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 <javascript:;> > > > > > > > > > > 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 > <javascript:;>>: > > > > > > > > > > > > > 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 <javascript:;> > > > > > > > > > > > > > > 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 > <javascript:;>>: > > > > > > > > > > > > > > > > > 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 <javascript:;>> > > > > > > > > > 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 <javascript:;> > > > >: > > > > > > > > > > > > > > > > > > > > thanks! > > > > > > > > > > > > > > > > > > > > On Thu, Feb 9, 2017 at 8:51 PM, Benjamin Roth < > > > > > > > benjamin.r...@jaumo.com <javascript:;> > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Yes it is > > > > > > > > > > > > > > > > > > > > > > Am 10.02.2017 00:46 schrieb "Kant Kodali" < > > > k...@peernova.com <javascript:;> > > > > >: > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > -- > > 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 > > > -- Sorry this was sent from mobile. Will do less grammar and spell check than usual.
