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
