You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@skywalking.apache.org by GitBox <gi...@apache.org> on 2021/05/24 08:18:29 UTC

[GitHub] [skywalking-banyandb] lujiajing1126 commented on pull request #2: Add definitions for Query module in flatbuffers

lujiajing1126 commented on pull request #2:
URL: https://github.com/apache/skywalking-banyandb/pull/2#issuecomment-846868529


   > @hanahmily @lujiajing1126 As you are doing the official query API rather than just testing, I prefer to consider the schema concept. From my understanding, the query API should not care which fields OAP is going to use for the query. It should care more about which fields have an index, or which kind of the index is better in the storage model.
   > 
   > The protocol level data type should more like `type=SEARCHABLE_ID`(represents trace id or segment id), or `type=TIMESTAMP`(represents start_time), etc.
   > 
   > We are designing BanyanDB closing to the APM field, but not for replacing OAP logic. We just leverage the benefit of data_model and private types. What do you think?
   
   I am trying to understand your idea. Are you arguing that the Query module should only rely on the general schema instead of the specific model like Trace, Metrics and Log.
   
   For example, query module should accept query as a format of logical expresses, `select("traceID")`, `projection(Gt(duration, 30ms))`, and return a general `RecordBatch` data structure containing schema of the record and data in bytes.


-- 
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:
users@infra.apache.org