Thank you Janne. Yes, these are random-access (scatter) reads - I've
decided on option 1; having also considered (as you wrote) that it will
never make sense to look at ranges of key3.
On Fri, Dec 30, 2016 at 3:40 AM, Janne Jalkanen
wrote:
> In practice, the performance you’re getting is likely
In practice, the performance you’re getting is likely to be impacted by your reading patterns. If you do a lot of sequential reads where key1 and key2 stay the same, and only key3 varies, then you may be getting better peformance out of the second option due to hitting the row and disk caches more
In the first case, the partitioning is based on key1,key2,key3.
In the second case, partitioning is based on key1 , key2. Additionally you
have a clustered key key3. This means within a partition you can do range
queries on key3 efficiently. That is the difference.
regards
On Tue, Dec 27, 2016 a
Yes sorry I missed the double parenthesis in the first case.
I may be a bit off here, but I don't think the coordinator pinpoints the row
but just the node it needs to go to.
It's more a case of creating smaller partitions, which makes for more even load
among the cluster and the node will not
Thank you Oskar. I think you may be missing the double parentheses in the
first example - difference is between partition key of (key1, key2, key3)
and (key1, key2). With that in mind, I believe your answer would be that
the first example is more efficient?
Is this essentially a case of the coor
The second one will be the most efficient.
How much depends on how unique key1 is.
In the first case everything for the same key1 will be on the same partition.
If it's not unique at all that will be very bad.
In the second case the combo of key1 and key2 will decide what partition.
If you
Wondering if there's a difference when querying by primary key between the
two definitions below:
primary key ((key1, key2, key3))
primary key ((key1, key2), key3)
In terms of read speed/efficiency... I don't have much of a reason
otherwise to prefer one setup over the other, so would prefer the
