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
I had searched in the issues and found no similar feature requirement.
Description
I suggest adding a new feature to BanyanDB that supports TTL (Time to Live) for tags and fields. This feature would enable BanyanDB to automatically remove specific tag or field data based on the TTL rules defined on a Group.
Currently, BanyanDB only supports TTL for the entire Group, which means that data can accumulate indefinitely, potentially causing storage issues. By implementing TTL for tags and fields, only relevant and recent data will be stored, which optimizes storage usage.
Furthermore, the proposed hot-warm-cold architecture could be utilized to set different TTL for cold, warm, or hot data, respectively.
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!
@sksDonni If you have any questions about this task, please let me know. Before submitting a PR, it's important to write a design document detailing how you plan to implement this feature.
About this, I think we need to update the protocol to support this. The server side can't / shouldn't determine which fields could be removed with time, unless OAP told so. Because in some cases(mostly for streaming), fields and tags are required until TTL reached.
Search before asking
Description
I suggest adding a new feature to BanyanDB that supports TTL (Time to Live) for tags and fields. This feature would enable BanyanDB to automatically remove specific tag or field data based on the TTL rules defined on a Group.
Currently, BanyanDB only supports TTL for the entire Group, which means that data can accumulate indefinitely, potentially causing storage issues. By implementing TTL for tags and fields, only relevant and recent data will be stored, which optimizes storage usage.
Furthermore, the proposed hot-warm-cold architecture could be utilized to set different TTL for cold, warm, or hot data, respectively.
Use case
No response
Related issues
No response
Are you willing to submit a pull request to implement this on your own?
Code of Conduct
The text was updated successfully, but these errors were encountered: