Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The requirement of two commands for Kvrocks #874

Closed
1 of 2 tasks
lrb1996 opened this issue Sep 14, 2022 · 5 comments · Fixed by #882
Closed
1 of 2 tasks

The requirement of two commands for Kvrocks #874

lrb1996 opened this issue Sep 14, 2022 · 5 comments · Fixed by #882
Assignees
Labels
enhancement type enhancement good first issue Good for newcomers help wanted Good for newcomers

Comments

@lrb1996
Copy link

lrb1996 commented Sep 14, 2022

Search before asking

  • I had searched in the issues and found no similar issues.

Motivation

I have a requirement which I hope you dear admins can fix. When we use Redis, we can easily know the memory usage of the specific key by using command "memory usage key " as well as the keyspace hits percentage of the specific key by using command "info". But for Kvrocks, we can't easily get the information by using commands. In conclusion, i'll appreciate it if you can solve this problem. Looking forward to your reply, thank you!

Solution

No response

Are you willing to submit a PR?

  • I'm willing to submit a PR!
@lrb1996 lrb1996 added the enhancement type enhancement label Sep 14, 2022
@git-hulk
Copy link
Member

Do you mean the disk space usage of key? Kvrocks stores its data in disk instead of the memory, so the memory usage of key is meaningless for Kvrocks.

@lrb1996
Copy link
Author

lrb1996 commented Sep 14, 2022

Thanks for your reply. I know that Kvrocks stores its data in disk instead of the memory, but i think it's also necessary to know the size of the specific key accurately, otherwize it may cause the abnormal increment of the cpu percentage or some other related indexes for the machine. As a dba, i need to contact the developers to focus the unusual key as fast as i find unusal indexes mentioned above of machines. So I wonder if there's a fast way to get the size of the specific key (disk space usage of key) clearly like Redis. Thanks.

@git-hulk git-hulk added help wanted Good for newcomers feature type new feature labels Sep 14, 2022
@git-hulk
Copy link
Member

Thanks for your clarification. It makes sense to export the value size of the specific key, and it should be possible since the RocksDB has a way to get the approximate size with the prefix if my memory serves.

@git-hulk git-hulk added good first issue Good for newcomers and removed feature type new feature labels Sep 14, 2022
@tanruixiang
Copy link
Member

Thanks for your clarification. It makes sense to export the value size of the specific key, and it should be possible since the RocksDB has a way to get the approximate size with the prefix if my memory serves.

@git-hulk Hi. Maybe u mean GetApproximateSizes. I am willing to do this task. Can you give me some guidance?

@git-hulk
Copy link
Member

git-hulk commented Sep 14, 2022

@tanruixiang sure, thanks for your interest. We want a command like Redis MEMORY USAGE except the usage should be disk space, and as you said we can use GetApproximateSizes to count the approximate size.

So what we need to do is:

  1. implement a command like DISK USAGE key and [SAMPLES count] is no need.
  2. Count the value size directly if the key type is a string, or we need to use GetApproximateSizes to get the key size with a prefix. The prefix should be composed of key and version since we use the version to identify the live subkeys. I think you can have a look at How Kvrocks Design Complex Structure On Rocksdb and come back to discuss if you still don't know how to do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement type enhancement good first issue Good for newcomers help wanted Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants