Thanks Jeff, the summary at the end is very insightful - something we also are observing.
On a related note, we do observe that the "first N clustering" doesn't exactly behave the way it is documented to. Is it related to this open ticket CASSANDRA-8646 <https://issues.apache.org/jira/browse/CASSANDRA-8646> ? On Mon, Dec 14, 2020 at 9:53 AM Jeff Jirsa <jji...@gmail.com> wrote: > Sometime around 2.0 or 2.1, it was changed from a "partition cache" to a > "head of the partition cache", where "head of the partition" means "first N > clustering". > > The reason individual rows are "hard" is the same reason most things with > Cassandra caching and consistency are "hard" - a clustering / row may not > change, but it may be deleted by a range delete that deletes it and many > other clusterings / rows, which makes maintaining correctness of an > individual row cache not that different from maintenance of the data around > it, which ends up looking a lot like "keep a part of the partition in > memory", which is basically what's there now. > > That said: > - The implementation is not great. I haven't looked into specifics but it > is incredibly rare to find a use case where it's a win, even on very narrow > partitions (you basically need workloads that are ALMOST immutable), partly > because: > - You're still caching the data on one replica of N, and caching the > converged result usually ends up to be a bigger win and easier to > manage/invalidate. So memcached/redis/etc outside of the result still > usually ends up better. > > > > > On Mon, Dec 14, 2020 at 9:44 AM Chidamber Kulkarni <chidam...@reniac.com> > wrote: > >> Hello All, >> >> Wondering if anyone has tried to modify the row-cache API to use both the >> partition key and the clustering keys to convert the row-cache, which is >> really a partition cache today, into a true row-cache? This might help with >> broader adoption of row-cache for use-cases with large partition sizes. >> Would appreciate any thoughts from the experts here. >> >> thanks, >> Chidamber >> >>