@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> 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>: > > > 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 > > > > > > > > > -- > 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 >
