You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we store all data in a single database table 'resource', which satisfies most scenarios. Event is a special resource in k8s, and its quantity is very large in general. If we put it in another table, we can handle it more conveniently and flexibly.
Why is this needed?
We have two main requirements to query the event resource:
We will use the field LastTimestamp of evnet to sort, but the data for this field is in the json data, so we cannot use the general clusterpedia query method.
As the number of clusters grows, the amount of event data is very large. Putting all the data in one table will cause query pressure on the database.
The text was updated successfully, but these errors were encountered:
Hi @calvin0327,
Thanks for opening an issue!
We will look into it as soon as possible.
Details
Instructions for interacting with me using comments are available here.
If you have questions or suggestions related to my behavior, please file an issue against the gh-ci-bot repository.
What would you like to be added?
Currently, we store all data in a single database table 'resource', which satisfies most scenarios. Event is a special resource in k8s, and its quantity is very large in general. If we put it in another table, we can handle it more conveniently and flexibly.
Why is this needed?
We have two main requirements to query the event resource:
We will use the field
LastTimestamp
of evnet to sort, but the data for this field is in the json data, so we cannot use the general clusterpedia query method.As the number of clusters grows, the amount of event data is very large. Putting all the data in one table will cause query pressure on the database.
The text was updated successfully, but these errors were encountered: