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

Add SHOW CARDINALITY to query language #7195

Closed
pauldix opened this issue Aug 23, 2016 · 18 comments
Closed

Add SHOW CARDINALITY to query language #7195

pauldix opened this issue Aug 23, 2016 · 18 comments
Assignees
Milestone

Comments

@pauldix
Copy link
Member

pauldix commented Aug 23, 2016

Proposal: Add a SHOW CARDINALITY query to the database. This should be something that can be scoped by database, measurement, tag key, or tag key/value pair. Each one of these queries could be delivered separately.

These are just some ideas to get the conversation started:

-- number of series in a database
SHOW SERIES CARDINALITY

-- number of series for every measurement in a database
SHOW SERIES CARDINALITY GROUP BY measurement

-- number of series in a measurement
SHOW SERIES CARDINALITY FROM "<measurement>"

-- number of series with a given tag key/value pair
SHOW SERIES CARDINALITY WHERE "<key>" = '<value>'

-- number of series from a measurement with a given tag key/value pair
SHOW SERIES CARDINALITY FROM "<measurement>" WHERE "<key>" = '<value>'

-- number of measurements in a database
SHOW MEASUREMENT CARDINALITY

-- number of tag keys in a database
SHOW TAG KEY CARDINALITY

-- number of tag keys in a measurement
SHOW TAG KEY CARDINALITY FROM "<measurement>"

-- number of fields in a database
SHOW FIELD KEY CARDINALITY 

-- number of fields in a measurement
SHOW FIELD KEY CARDINALITY FROM "<measurement>"

-- number of unique tag values
SHOW TAG VALUE CARDINALITY WITH KEY = '<tag key>'

-- number of unique tag values in a measurement
SHOW TAG VALUE CARDINALITY FROM "<measurement>" WITH KEY = '<tag key>'

The top two queries are probably the most important and easiest to wire up to begin with.

Use case: As a troubleshooting method this will help users determine which measurements, databases, or tags are causing problems. For users building out data exploration UIs, they'll be able to show cardinality numbers before measurements or tag keys are expanded (kind of like faceted search).

For users monitoring their databases, they would be able to use this functionality to trigger alerts if for some reason the cardinality of a measurement, database or tag key gets too high.

@jackzampolin
Copy link
Contributor

@beckettsean
Copy link
Contributor

beckettsean commented Aug 23, 2016

I like the idea and the syntax works for me. I would perhaps extend it to include SHOW DATABASE CARDINALITY as some users have hundreds of databases.

There's been a long-standing request for returning DISTINCT tag values (#3880), so if SHOW TAG VALUE CARDINALITY is implemented, perhaps we could also implement a SHOW DISTINCT TAG VALUES query as well?

@pauldix
Copy link
Member Author

pauldix commented Aug 23, 2016

@beckettsean I think SHOW DISTINCT TAG VALUES already exists as SHOW TAG VALUES WITH KEY = '<key>'

From reading that issue, what it looks like is they actually want COUNT(DISTINCT(...)) which would be the same as what SHOW TAG VALUE CARDINALITY would return.

@beckettsean
Copy link
Contributor

@pauldix you are correct, it's already possible to get the DISTINCT via the show query, and the SHOW CARDINALITY would give the COUNT(DISTINCT()) equivalent. Ignore me!

@seb-koch
Copy link

seb-koch commented Sep 23, 2016

+1, definitely required and a potentially mighty feature.
We are saving lots of sensor information and want to display counts of the tags in grafana, such as:

  • of connected sites

  • of unique sensors

  • of unique sensor events

  • of disconnected sites

    ...
    but all of these are tags unfortunately.

@biker73
Copy link

biker73 commented Jan 30, 2017

+1 - this would be an extremely powerful feature.

@lpic10
Copy link

lpic10 commented Jan 30, 2017

Maybe InfluxDB should implement schema discovery via standard SQL, as some RDBMS do.

MySQL implemented this years ago using the read-only information_schema views, in addition to the usual "SHOW ..." commands.

Interesting info, section "INFORMATION_SCHEMA as Alternative to SHOW Statements" : https://dev.mysql.com/doc/refman/5.7/en/information-schema.html

@aschumilin
Copy link

+1

@Codelica
Copy link

This would be a very welcome addition! My current solution to monitor the number of series in a few important measurements involves a script calling "SHOW SERIES FROM XXX" and doing an external count, which unfortunately seems to randomly kill my Influx daemon at this point. (counts are over 150k) Would love to see this to help keep an eye on things at a more granular level.

@sandebains
Copy link

Could we also have these functionality group by time?

For example finding unique tags with 1m,5m time window

@benbjohnson benbjohnson mentioned this issue Jul 26, 2017
6 tasks
@benbjohnson benbjohnson self-assigned this Jul 26, 2017
@ghost ghost removed the review label Aug 16, 2017
@denniswalker
Copy link

+1

@mvadu
Copy link
Contributor

mvadu commented Nov 13, 2017

@beckettsean where are we with this feature? I see #3760 also asking for similar feature, and was told this issue is tracking it. I also see #8636 trying to add the same queries that @pauldix mentioned above. But none of them work in latest v1.3.7 [2017-10-26].

@tlanford
Copy link

Not seeing it working as well.

@timhallinflux timhallinflux added this to the 1.4.0 milestone Nov 30, 2017
@timhallinflux
Copy link
Contributor

this feature is in v.1.4. It is not part of v1.3.x

@maxp-edcast
Copy link

If it is v1.4 where is the docs for it?

@gaddman
Copy link

gaddman commented Apr 1, 2018

@maxp-edcast I think this is what you're after, your link referred to v1.2 and this was implemented in 1.4. https://docs.influxdata.com/influxdb/v1.5/query_language/spec/#show-cardinality

@timhallinflux
Copy link
Contributor

@gaddman -- you are correct!! Thanks for pointing out the update in the query language.

The 1.2 reference is the "old" way. It was more of an estimate and had some challenges in terms of accuracy -- particularly with the enterprise edition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests