CODEWITHSUNDEEP
cassandracassandra-2.0
mrmadou
mrmadou

Reputation: 101

Cassandra slow query execution in an empty table

I'm using apache-Cassandra-2.2.4 and I have encountered this problem :

When I execute select * from TRACKING ; it takes more than 70 sec to get the result Despite the fact that the table is empty (0 rows).

As a first solution I execute truncate TRACKING and the problem is fixed (return instantly the result).

Can you help me to know the root cause? I can't truncate the table in my application.

Upvotes: 0

Views: 577

Answers (2)

Chris Lohfink
Chris Lohfink

Reputation: 16410

A SELECT * FROM table query with no partition key has to iterate through your entire ring until it reaches the limit for the query. For each range in the token ring it will essentially be a sub query that the coordinator will make one after another. In particular if you use vnodes it can be a lot of these "sub queries" since it will have more ranges to cover before exhausting the ring (which you will do with 0 rows).

Also since you are essentially doing a huge scatter gather request to the entire cluster, any node hitting GCs or network slowness will impact the query pretty significantly. Since the requests will probably be sequential (there is some parallelism based on partition counts) the individual slowdowns can really hurt it.

Upvotes: 2

Adam Holmberg
Adam Holmberg

Reputation: 7375

The likely cause is that you have a bunch of data that was deleted, and you were seeing the effects of reading many tombstones in your full table scan. You could confirm by enabling tracing on the query. Truncating would remove the tombstoned data.

This article explains the tombstone pitfall and root cause: http://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets

Upvotes: 4

Related Questions