lujiajing1126 opened a new pull request #3:
URL: https://github.com/apache/skywalking-banyandb/pull/3
## Motivation
As we've discussed this morning, in order to eliminate ambiguity of
relationship between key and values in `PairQuery`, I would like to change the
structure of `PairQuery` to only allow a single operator in `PairQuery`.
## Design
Rather than put multiple operators and values in one `PairQuery`, we may use
the following methodology to compose conditional query,
- Range operation can be implemented by submitting two conditions, i.e.
`[{key: duration, op: GT, values: [minValue]}, {key: duration, op: LE, values:
[maxValue]}]`
- Having: a single condition `{key: peer.services, op: HAVING, values:
[1,2,3]}`
- Composite indexes: For example, in order to make composite index
“colA-colB-colC-colD” work, all four columns should be required, i.e. colA,
colB and colC must not be skipped and only the condition for the rightmost
column may not be EQUAL. `[{key: colA, op: EQ, values: [valA]}, {key: colB, op:
EQ, values: [valB]}], {key: colC, op: EQ, values: [valC], {key: colD, op: EQ,
values: [valD]}}`
Following the idea, the Query module should be able to
1. merge operations for the same key,
2. decide whether any composite index can be made use of and then choose the
most suitable and restrictive one to improve performance.
In the future, we may also support HINT to force the query module to use
some indexes.
## Alternatives
Use `Union of Enums`, but it is not supported by FlatBuffers. See issue
https://github.com/google/flatbuffers/issues/5791
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
