This message was deleted.
# troubleshootings
Slackbot
03/06/2023, 12:11 PMThis message was deleted.
v
Vijay Narayanan
03/06/2023, 2:07 PMthe error bounds can vary depending on the size of the sketch use
Copy code
HLL_SKETCH_ESTIMATE_WITH_ERROR_BOUNDS(ds_HLL(tmp_hash, 4, 'HLL_4'),3)k
khajjiar trip
03/06/2023, 4:10 PMthanks. but whats the logic behind this. i would have imagined that with lgk=4, we would use lesser no of bits to represent the aggregate field and hence would get less no of unique values.
I cannot imagine why the could would go up!
b
Ben Krug
03/06/2023, 9:10 PMI don't understand all the math, but estimates can be off both ways - over or under. I think of it as, OK I have a few hash values here, from that, guess how many of the inputs were actually unique? I get that it's kind of surprising that it doesn't remember that it started with 50 values, so it must be less than 50, but afaict it doesn't. Seems like a good question for #datasketches in ASF slack, so I just asked there - https://the-asf.slack.com/archives/CHWKFEHUZ/p1678136969191449
Ben Krug
03/06/2023, 9:52 PMHere's a response from there:
Ben Krug
03/06/2023, 9:52 PMAlexander Saydakov [1:48 PM]
keeping this count is an extra resource. what are the chances that it is going to help? usually the distinct count is much less than total count. I would suggest to start from a desired accuracy. Say, you want to be within 1% with 95% confidence. That translates to a particular K. Unbiassed estimate means it is as likely to overestimate as underestimate, and that is a good property. In some rare cases in some particular circumstances the estimate might be higher than total count. Why do you think it is a problem if you are guaranteed to be, say, within 1% with 95% confidence?
Ben Krug
03/06/2023, 9:52 PMSo, it's by design
Ben Krug
03/06/2023, 9:53 PMk
khajjiar trip
03/07/2023, 5:26 AMthanks Ben, i didnt know about that channel and dont have access, so thanks for carrying it forward.
"within 1% with 95% confidence" - where can i find a source on this info to understand this more?
khajjiar trip
03/07/2023, 5:33 AMkhajjiar trip
03/07/2023, 10:36 AMAm i reading the lgK=4 chart right?
khajjiar trip
03/07/2023, 10:39 AM Copy code
LgK=4, LgT=20, factor=.83266, RSE=0.20g
Gian Merlino
03/07/2023, 2:40 PMwith
APPROX_COUNT_DISTINCT_DS_HLL(tmp_hash, 4, 'HLL_4')Gian Merlino
03/07/2023, 2:40 PMi'm wondering why you're wanting to use lgK = 4?
Gian Merlino
03/07/2023, 2:41 PMthe default is 12 which is pretty balanced between size/speed/accuracy
Gian Merlino
03/07/2023, 2:41 PMan error table i made for a talk last year
Gian Merlino
03/07/2023, 2:41 PMthe table doesn't go below 10 because the errors are too high imo
k
khajjiar trip
03/08/2023, 2:22 AM"i'm wondering why you're wanting to use lgK = 4?"
well, I am using groupBy queries and they being resource intensive, crashed at lgk=12 with wanting more aggregate buffer space.
Asking for more buffer space from the OPS team for my druid prod servers is also a big task.
So i started looking into the queries and found a variable to tweek. and brought the lgk down to 4 from 12. which worked.
Now that i know what it does, i would revert it back to 12 and also look into the topN queries. 🙂
khajjiar trip
03/08/2023, 2:25 AM"an error table i made for a talk last year"
Also, can i have link to the talk, if its public.
g
Gian Merlino
03/08/2023, 6:20 PMit wasn't recorded but i hope to do a recorded one at some point!
Gian Merlino
03/08/2023, 6:21 PMah, got it. i guess you got a resource limit exceeded error?
Gian Merlino
03/08/2023, 6:21 PMyou could also ask your ops team to enable disk spilling using
druid.query.groupBy.maxOnDiskStoragek
khajjiar trip
03/09/2023, 4:42 AMI am afraid that might add disk-io latencey to an already heavy query -
25s currently with a ui timeout of 30s.
Also, it would result in regression + perf. testing all the other existing queries.
I want to keep the impact to a minimum. So looking into replacing groupBy with topN
v
Vijay Narayanan
03/09/2023, 1:45 PMyou could page to disk and enable parallel combine in the historical. This could get you some performance benefit if the merge across segment results is the bottle neck
k
khajjiar trip
03/09/2023, 8:56 PMThanks Gian and Vijay
Some observations:
case1: druid.query.groupBy.maxOnDiskStorage=1Gb
response time: 63s
case2:
druid.query.groupBy.maxOnDiskStorage=1Gb + “numParallelCombineThreads”:10response time: 97s Latency seems to be increasing
g
Gian Merlino
03/09/2023, 11:41 PMyeah that's good to know! based on other cases i've seen, i'm not sure parallel combine actually helps in most cases. we're thinking about moving away from that and toward a different approach for big groupBys
v
Vijay Narayanan
03/10/2023, 7:05 AMis tmp_hash a number or guid?
k
khajjiar trip
03/10/2023, 7:07 AMits a 41 char guid
v
Vijay Narayanan
03/10/2023, 7:09 AMhmmm.....the sketch is a lot faster on number fields. You could convert the guid to a number using a hash function in the pipeline before Druid. This will likely speed up the query a lot