RE: about the performance of select * from tbl
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 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
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? -- This email has been checked for viruses by AVG. https://www.avg.com
Re: about the performance of select * from tbl
Yes, you CAN change the fetch size to adjust how many pages of results are returned. But, if you have a million rows, you may still do hundreds or thousands of queries, one after the next. Even if each is 1ms, it's going to take a long time. What Dor suggested is generating a number of SELECT statements, each of which would return part of the table (using TOKEN()), that you can execute in parallel. This will end up being much faster than trying to tune the single SELECT. On Tue, Apr 26, 2022 at 7:35 AM 18624049226 <18624049...@163.com> wrote: > Thank you for your reply! > > What I want to know is that the data volume of this table is not massive. > If the logic of CQL cannot be modified, just inside Cassandra, are there > any parameters that can affect the behavior of this query? For example, the > fetchSize parameter of other databases? > 在 2022/4/26 21:18, Dor Laor 写道: > > select * reads all of the data from the cluster, obviously it would be bad > if you'll > run a single query and expect it to return 'fast'. The best way is to > divide the data > set into chunks which will be selected by the range ownership per node, so > you'll > be able to query in parallel the entire cluster and maximize the > parallelism. > > If needed, I can provide an example for this > > On Tue, Apr 26, 2022 at 3:48 PM 18624049226 <18624049...@163.com> 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? >> >
Re: about the performance of select * from tbl
Thank you for your reply! What I want to know is that the data volume of this table is not massive. If the logic of CQL cannot be modified, just inside Cassandra, are there any parameters that can affect the behavior of this query? For example, the fetchSize parameter of other databases? 在 2022/4/26 21:18, Dor Laor 写道: select * reads all of the data from the cluster, obviously it would be bad if you'll run a single query and expect it to return 'fast'. The best way is to divide the data set into chunks which will be selected by the range ownership per node, so you'll be able to query in parallel the entire cluster and maximize the parallelism. If needed, I can provide an example for this On Tue, Apr 26, 2022 at 3:48 PM 18624049226 <18624049...@163.com> 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?
Re: about the performance of select * from tbl
select * reads all of the data from the cluster, obviously it would be bad if you'll run a single query and expect it to return 'fast'. The best way is to divide the data set into chunks which will be selected by the range ownership per node, so you'll be able to query in parallel the entire cluster and maximize the parallelism. If needed, I can provide an example for this On Tue, Apr 26, 2022 at 3:48 PM 18624049226 <18624049...@163.com> 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? >
about the performance of select * from tbl
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?
