question

Hello,

well, in most cases that's the least expensive solution to accommodate your needs. If you have these three tables, it means that your app workflow will need all three access patterns to get users. Most likely you will read more often than you write, so it is even more true that duplicating the data at write time is a performance gain on the long run.

There are other solutions (creating indices or even materialized views), which however, depending on the use case, may generate more load to the nodes and higher latency.

If you are concerned about having the best read performance, performing multiple writes is still your best option - and your client may issue the writes in parallel, spread over nodes compatibly with your replication factor.

In some cases you may also want to consider grouping your write statements inside a batch (in this case it would be a logged multi-table batch), but even that comes with some performance penalty.

Yes, you do need to do multiple writes to keep the denormalised tables in sync.

It is true that multiple table updates can be expensive but it is a tradeoff in preference to making reads really fast because you do not need to do lookups on multiple tables to retrieve the data -- for each of your app queries, you are just reading one table.

Cassandra can achieve single-digit millisecond latency by optimising reads to as little as a single disk seek. Unlike traditional RDBMS, denormalised tables have a preference for faster data retrievals at the expense of multiple writes. Cheers!