feat(query): add call stats functions

[everpcpc]

I hereby agree to the terms of the CLA available at: https://databend.rs/dev/policies/cla/

Summary

Summary about this PR

Changelog

• New Feature

Related Issues

Fixes #issue

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Updated
databend	⬜️ Ignored (Inspect)		May 30, 2022 at 4:44AM (UTC)

[mergify]

Thanks for the contribution!
I have applied any labels matching special text in your PR Changelog.

Please review the labels and make any necessary changes.

[BohuTANG]

Oops, .github/actions/check/action.yml Conflicting

[everpcpc]

ask @drmingdrmer for advice, are there any needs to limit request to meta?

[drmingdrmer]

ask @drmingdrmer for advice, are there any needs to limit request to meta?

Yes, if it's possible. The estimated max throughput is about 30,000 writes per second for now.

[everpcpc]

Yes, if it's possible. The estimated max throughput is about 30,000 writes per second for now.

The stats call is just read, no write at all. Would that make any difference?

[drmingdrmer]

Yes, if it's possible. The estimated max throughput is about 30,000 writes per second for now.

The stats call is just read, no write at all. Would that make any difference?

A read does not need to replicate a raft-log or to persist anything on a disk. It would be cheaper.

If the total RPS is under 5,000 there should not be a concern.

[everpcpc]

Yes, if it's possible. The estimated max throughput is about 30,000 writes per second for now.

The stats call is just read, no write at all. Would that make any difference?

A read does not need to replicate a raft-log or to persist anything on a disk. It would be cheaper.

If the total RPS is under 5,000 there should not be a concern.

thx~
Currently the list_tables operation would result in a RPS of total table count. But we only need the table count. Would a list_id_value or list_keys call different from common read calls?
Moreover, would it be ok for meta to provide some api for stats grouped by prefix (such as tenant id) ?

[drmingdrmer]

Would a list_id_value or list_keys call different from common read calls?

list_id_value can be implemented with a prefix-list RPC to metasrv.
list_keys can not be expressed with KVApi yet.

Moreover, would it be ok for meta to provide some api for stats grouped by prefix (such as tenant id) ?

metasrv does not know what the delimiter is for an application, although traditionally it is a slash /.
And maintaining the counts of every prefix will result in unnecessary write-amplification.

Thus IMHO, count by the prefix should be implemented on the application side:

When creating/dropping/undropping/renaming a table, also update a counter record.