On Sat, Feb 11, 2017 at 3:03 AM, 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>: > > @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 > > > Take a look at https://github.com/edwardcapriolo/ec/blob/master/src/test/java/Base/MvEventual3Node.java . While this type of testing is not a rigorous proof typically a few thousand read/write will detect week consistency. I ran this test with up to 100,000 which is a good indication that MVs on the same primary key are strongly consistent. Feel free to play with other MVs with different combinations of primary key columns and see what can be fleshed out.
