If the number of rows is known and bounded and would be under 100 MB in size, I would suggest adding an artificial partition key so that all rows are in one partition. I recommend this technique for something like an application settings table that is retrieved infrequently (like on app start-up) but needs all rows at once. If it is often accessed, this strategy could create hot spots or potential availability concerns.
If this is more about analytics and the row count is unbounded, I would pursue something like Spark OR re-design the model so that you do have some kind of partition (and maybe clustering) keys. I’m always telling app teams that more in-parallel queries are a very good option for Cassandra. My bottom line is this: the BEST way to scale Cassandra is NOT tuning queries, but designing the tables to easily answer what you need with proper partitioning. Sean R. Durity From: Joe Obernberger <joseph.obernber...@gmail.com> Sent: Tuesday, April 26, 2022 1:10 PM To: user@cassandra.apache.org; 18624049226 <18624049...@163.com> Subject: [EXTERNAL] Re: about the performance of select * from tbl This would be a good use case for Spark + Cassandra. -Joe On 4/26/2022 8:48 AM, 18624049226 wrote: We have a business scenario. We must execute the following statement: select * from tbl; This CQL has no WHERE condition. What I want to ask is that if the data in this table is more than one million or more, what methods or parameters can improve the performance of this CQL? ________________________________ [Image removed by sender. AVG logo][avg.com]<https://urldefense.com/v3/__https:/www.avg.com/internet-security__;!!M-nmYVHPHQ!LXIUqM_3oQ6NQh9DsGfUplOMuPHZ9AHoRrvgwyAsZl8-vKAyMttKCW1TAuM5fcK_BIfSZ-0azIAR_ELw4yBPp3I3kUmRjnCW_w$> This email has been checked for viruses by AVG antivirus software. www.avg.com [avg.com]<https://urldefense.com/v3/__https:/www.avg.com/internet-security__;!!M-nmYVHPHQ!LXIUqM_3oQ6NQh9DsGfUplOMuPHZ9AHoRrvgwyAsZl8-vKAyMttKCW1TAuM5fcK_BIfSZ-0azIAR_ELw4yBPp3I3kUmRjnCW_w$> INTERNAL USE
