@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 1
On Fri, Feb 10, 2017 at 1:13 PM, Benjamin Roth
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
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 mutat
No your example has different PRIMARY keys but same PARTITION keys. Same
partition keys generate same token and will always go to the same host.
2017-02-10 19:58 GMT+01:00 Kant Kodali :
> In that case I can't even say same partition key == same row key
>
> The below would be different partition k
PRIMARY KEY ( (Partition key), Clustering Keys) :
On Fri, Feb 10, 2017 at 10:59 AM DuyHai Doan wrote:
> 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
> wrote:
>
> > Same partition key:
> >
> > P
In that case I can't even say same partition key == same row key
The below would be different partition keys according to you right?
PRIMARY KEY ((a, b), c, d) and
PRIMARY KEY ((a, b), d, c, e)
On Fri, Feb 10, 2017 at 10:48 AM, Benjamin Roth
wrote:
> Same partition key:
>
> PRIMARY KEY ((a, b)
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
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)
>
> D
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 K
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
wrote:
> There are use cases where the part
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
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
(w
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
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 t
Hi Kant
Is it clear now?
Sorry for the confusion!
Have a nice one
Am 10.02.2017 09:17 schrieb "Kant Kodali" :
thanks!
On Thu, Feb 9, 2017 at 8:51 PM, Benjamin Roth
wrote:
> Yes it is
>
> Am 10.02.2017 00:46 schrieb "Kant Kodali" :
>
> > If reading from materialized view with a consistency le
See my latest comment
2017-02-10 14:33 GMT+01:00 Salih Gedik :
> I agree with Brian. As far as I am concerned an update of materialized
> view is an async operation. Therefore I don't believe that you'd get most
> up to date data.
>
> Salih Gedik
>
>
> > On 10 Feb 2017, at 16:11, Brian Hess wrot
The primary reason I avoided integrating a daemon into the Cassandra
process was the increase in heap pressure and further muddying of the
profile of heap usage. We've already seen that mixing read/write,
compaction, streaming, and repair in the same JVM causes a nasty mix of
allocation patterns th
I agree with Brian. As far as I am concerned an update of materialized view is
an async operation. Therefore I don't believe that you'd get most up to date
data.
Salih Gedik
> On 10 Feb 2017, at 16:11, Brian Hess wrote:
>
> This is not true.
>
> You cannot provide a ConsistencyLevel for th
Basically MV updates are processed when a mutation is applied. For MV
replicas that stay local, MV mutations are also applied directly (see
StorageProxy.mutateMV). For remote MV mutations, a batch is created.
Maybe I am wrong but code is somehow contradictory:
TableView.pushViewReplicaUpdates:
//
This is not true.
You cannot provide a ConsistencyLevel for the Materialized Views on a table
when you do a write. That is, you do not explicitly write to a Materialized
View, but implicitly write to it via the base table. There is not consistency
guarantee other than eventual between the bas
thanks!
On Thu, Feb 9, 2017 at 8:51 PM, Benjamin Roth
wrote:
> Yes it is
>
> Am 10.02.2017 00:46 schrieb "Kant Kodali" :
>
> > 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
20 matches
Mail list logo
