>So it looks like you have a numeric value being stored here in the string
>column. Are you sure that you are properly zero-padding when creating your
>key? For example if you accidentally scan from "50_..." to "80_..." you
>will end up scanning a huge portion of your table.

i'm sure they are properly zero-padding.


>What client version are you using? 1.7.0?

i used 1.6.0


>Looks like you got the metrics from the kudu master, not a tablet server.
>You need to figure out which tablet server you are scanning and grab the
>metrics from that one.

oh i have checked the metrics and find that rows_scanned is not much
more than rows_returned.

let me describe the situation. data is like below, i add a column
filter on dimension00 with value 'iphone',

and the rows_scanned is about 5 times more than the rows_returned, so
i think it is reasonable.

key              dimension00

000001_time_0    iphone

000001_time_1    android

000001_time_2    ipad

000001_time_3    windows_phone

000001_time_4    unkown


in addition, the leader of the tablet which store the target partition
was killed by mistake, and then a new leader comes up, i found that
scan performance was much better. all server config is same, the slow
leader's workload is lower than the new one, but it's performance is
bad...

do you have some config suggestions?

Reply via email to