skywalking icon indicating copy to clipboard operation
skywalking copied to clipboard

[Feature] Optimize Index Definition for BanyanDB Module in OAP

Open hanahmily opened this issue 1 year ago • 3 comments

Search before asking

  • [X] I had searched in the issues and found no similar feature requirement.

Description

The current index definition for the BanyanDB module in OAP needs optimization to increase efficiency and improve performance. This issue focuses on moving different identifiers from indexRule to Entity in Measure and simplifying the network_address_alias entity.

Details:

  1. Common Metrics: Move service_id from indexRule to Entity in Measure. This change will streamline the process of accessing the service information by centralizing the identifiers into Entity within Measure.

  2. Relation Metrics: Move service_id, instance_id, and endpoint_id to Entity. By moving these identifiers to Entity, we can improve the retrieval of relation metrics and enhance the overall performance of the system.

  3. Network_address_alias: Retain only last_update_time_bucket. Simplifying the network_address_alias will reduce unnecessary complexity and improve efficiency.

The proposed changes are expected to optimize the index definitions, improve the system's performance, and simplify the overall structure of the BanyanDB module in OAP.

Use case

No response

Related issues

No response

Are you willing to submit a pull request to implement this on your own?

  • [ ] Yes I am willing to submit a pull request on my own!

Code of Conduct

hanahmily avatar Nov 02 '23 16:11 hanahmily

So, this is only OAP side code change, and the protocol between OAP and DB is stable.

wu-sheng avatar Nov 03 '23 14:11 wu-sheng

@hanahmily I removed this from 9.7 as it seems not required in the version.

wu-sheng avatar Nov 20 '23 05:11 wu-sheng

According to the latest discussion, we need to make BanyanDB APIs and implementation support accept multiple series definitions, rather than one. Each series definition could have multiple fields. This could provide better query support in following typical scenarios

  1. Query metrics by ts and entity ID.
  2. Store all query relative fields in one file. Nowadays, some are in series ID files, and others are in the tags family.

FYI @hanahmily

wu-sheng avatar Apr 11 '24 08:04 wu-sheng