Cost of availability is a fair question at some level of the discussion. In my
experience, high availability is one of the top 2 or 3 reasons why Cassandra is
chosen as the data solution. So, if I am given a Cassandra use case to build
out, I would normally assume high availability is needed,
Well you could always do it like this
cqlsh> CREATE TABLE dating.visits2 (user_id int, visitor_id int, visit_month
int, visit_date int, primary key (user_id, visitor_id, visit_month)) WITH
CLUSTERING ORDER BY (visitor_id ASC, visit_month DESC );
This means that if you have, clearly, 6 months,
What you propose is another debate
Most of the time there are a product department and a tech department (I'm
sure it is your case at netapp)... I'd like to have a voice loud enough to
influence product requirements but it is not the way it works. I'm paid to
make miracles and not to explain to
The 2 tables you propose Stefan can not natively order rows by time (they will
be ordered by visitor_id), excepted if you sort rows after the select.
So what? I think this is way better than dealing with MV which you will get
inconsistent eventually. Do you want to have broken MV or you want to
Hi Stefan
Happy to see that our use case interest you :-)
I'm not sure that I explained well what we want.
Imagine that sequence of events :
- Julia visits Joe at t1
- Julia visits Joe at t2
- Karen visits Joe at t3
- Silvia visits Joe at t4
- Karen visits Joe at t5
- Karen visits Joe at t6
-
