Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upTrie Index + DFA for supporting globbing/wildcard queries #303
Conversation
This comment has been minimized.
This comment has been minimized.
codelingo
bot
commented
Jul 8, 2019
|
cannot apply patch to target branch |
This comment has been minimized.
This comment has been minimized.
dgryski
commented
Jul 8, 2019
|
Is there a point where the trigram index is better or is the trie index always superior? |
This comment has been minimized.
This comment has been minimized.
codelingo
bot
commented
Jul 9, 2019
|
cannot apply patch to target branch |
This comment has been minimized.
This comment has been minimized.
|
@dgryski, |
This comment has been minimized.
This comment has been minimized.
codelingo
bot
commented
Jul 11, 2019
|
cannot apply patch to target branch |
5 similar comments
This comment has been minimized.
This comment has been minimized.
codelingo
bot
commented
Jul 11, 2019
|
cannot apply patch to target branch |
This comment has been minimized.
This comment has been minimized.
codelingo
bot
commented
Jul 15, 2019
|
cannot apply patch to target branch |
This comment has been minimized.
This comment has been minimized.
codelingo
bot
commented
Jul 21, 2019
|
cannot apply patch to target branch |
This comment has been minimized.
This comment has been minimized.
codelingo
bot
commented
Jul 21, 2019
|
cannot apply patch to target branch |
This comment has been minimized.
This comment has been minimized.
codelingo
bot
commented
Jul 23, 2019
|
cannot apply patch to target branch |
This comment has been minimized.
This comment has been minimized.
gaoxp
commented
Aug 14, 2019
•
|
hi,when i use trie index instead of trigram index i find a problem, when i find metrics like a.b.*.*.*.c, goroutine which serve this request will panic,do you have same problem? also i find when go-carbon run one day or two day, carbonserver accour too many close-wait tcp connection, i don't understand why so many close-wait connections. |
This comment has been minimized.
This comment has been minimized.
Trie enabled version of go-carbon is not in production in the Booking currently. We are running 9b6b133 (current master) and don;t observe this problem. Can you confirm that you observe the same problem with 9b6b133 and if so - open a separate issue? |
This comment has been minimized.
This comment has been minimized.
@gaoxp Is it possible for you to share us the stack trace? |
This comment has been minimized.
This comment has been minimized.
gaoxp
commented
Aug 15, 2019
I try to fix this problem, the stack trace may different from original code,but it is sure that use trie index will cause this panic problem. |
This comment has been minimized.
This comment has been minimized.
gaoxp
commented
Aug 15, 2019
I don't observe the same problem with [9b6b133],just for trie-index version. |
This comment has been minimized.
This comment has been minimized.
|
@gaoxp I am unable to reproduce your problem. But from the stack trace, it looks like trieIdx isn't initialized. |
This comment has been minimized.
This comment has been minimized.
gaoxp
commented
Aug 15, 2019
ok, I use trigram index instead of trie index when i find a.b.*.*.*.f,and now it runs normal,thank you |
291ffc1
to
a28376a
This comment has been minimized.
This comment has been minimized.
gaoxp
commented
Aug 30, 2019
•
|
hello @bom-d-van, can you add fallback to filesystem logic when trie index not finish initial,becase i find when trie index not initialled, carbonserver not work well, and it will take some time to complete trie index initial,during this time, i can't see any metric use grafana. |
This comment has been minimized.
This comment has been minimized.
|
@gaoxp it's a valid point, I will add the relevant logics. |
This comment has been minimized.
This comment has been minimized.
@gaoxp I have pushed a simple fix for it. Though this is a problem shared by both trigram and trie indexing. |
This comment has been minimized.
This comment has been minimized.
@dgryski after some production testing and more understandings that I gained while working on this, my answer to this question boils down to it depends. There are at least one types of queries that I know of trigram performs better, that is if there is keywords extracted from the query that is able to narrow down the result. (For example, abc.keyword1.xxx.yyy.zzz, and there are a high numbers of metrics matching this pattern abc..xxx.yyy.zzz), because there are leading stars in the query, trie+dfa would have too go through every one of them. (thus we incorporated some levels of trigrams in trie nodes and performs some early checks to make it works a little bit better for trie+dfa, (however, I think it might not be a very good and generic solution)) However, there is some clear advantage on trie+dfa, which is less memory consumption (around 1/5 of trigram) and faster indexing time (also around 1/5 of trigram). And in the majorities of the queries that I found in our production environment, trie+dfa is a clear winner. (in our latest test on one of the cluster, trie+dfa's 99th percentile of request time is around 1/5 of trigram) @azhiltsov is helping on testing it on more our prod clusters to have more understandings and feedback. |
This comment has been minimized.
This comment has been minimized.
|
@azhiltsov @lomik @dgryski I think this PR is mature enough for a formal review now. There might be unknown bugs and more optimizations could be done, but we could address them when we run into them. |
This comment has been minimized.
This comment has been minimized.
dgryski
commented
Oct 10, 2019
|
Does this need fuzz tests for the query engine? |
This comment has been minimized.
This comment has been minimized.
|
@dgryski It's a nice idea. Given both metric paths and queries are user inputs, fuzz test might help! |
24b937f
into
lomik:master
bom-d-van commentedJul 8, 2019
•
edited
DFA implementation inspired by rsc: https://swtch.com/~rsc/regexp/regexp1.html
An alternative metric indexing implementation to trigram index. This implementation is built to support 10+ millions metrics per go-carbon instance (which becomes feasible after cwhisper support).
Currently only benchmark against a subset of our production queries, but already shows good potential. 92% of the queries is 1.34 - 3300.71 times faster. And the (1.02 - 18.29 times) slower queries is because of using leading star in a query nodes, which is possible to be re-written to become faster than the original query in trigram.
But still, more tests and changes are on the way.
Linking relevant issues that might be able to be resolved by this new implementation:
#202
#301