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

Joining series #3860

Closed
esecules opened this issue Aug 26, 2015 · 7 comments
Closed

Joining series #3860

esecules opened this issue Aug 26, 2015 · 7 comments

Comments

@esecules
Copy link

Is there a way to join two time series together like you had in the v 0.8 documentation?https://influxdb.com/docs/v0.8/api/query_language.html

@beckettsean
Copy link
Contributor

All series in a given measurement are automatically merged unless explicitly filtered out by the WHERE clause.

There is no way to join series from two different measurements.

@sstarcher
Copy link

@beckettsean so if we have 2 separate series that we want to do math against we would have to feed those metrics into something and have it generate a third series and put that into influxdb? I'm thinking of metrics like total disk space, used disk space, and being able to calculate disk used % based off of those 2 series. Is the intent for us to feed 3 series into influxdb instead of calculating the third?

@esecules
Copy link
Author

I believe it is intended that we would put free and used space as values in the same time series. A calculated column is not required.

@beckettsean
Copy link
Contributor

@sstarcher what @esecules says is correct. Measurements are containers of many many series. Any series within a measurement can be trivially "merged" or queried together with any other series in that measurement.

So for total disk space: SELECT sum(value) FROM disk_space or whatever. For used disk space: SELECT SUM(value) FROM used_disk_space. In this scenario, it's not possible to calculate used_disk_space/total_disk_space because they are separate measurements.

If you have total disk and used disk as multiple fields in the same measurement, then you can do this: SELECT used_disk/total_disk AS disk_percent_full FROM disk. In this case, used_disk and total_disk are fields on the measurement disk, and each needs to be stored with every point.

@Samuel1989
Copy link

@beckettsean Is this something that is likely to become available? In my mind I compare the Influx structure to that of a traditional relational database (granted this is wrong, but the query structure makes it so).

I kind of make the relation that measurements are tables and series are columns and because of this I have been structuring my data as such.

Now I want to be able to run cross measurement queries to display high level overviews of my data but it seems this isn't possible.

I guess there are some options:

  • Restructure my data (I am not sure this is possible now, due to the amount of data collected) so series I want to cross query are stored under the same measurement.
  • Create a third party agent to query the two measurements independently and store the result into a third measurement.
  • Wait until cross measurement queries become available (if they are planned to become available).

It would be nice to gather your thoughts on whether or not this should/will be possible in the future.

@beckettsean
Copy link
Contributor

Is this something that is likely to become available?

Short-term, no. I think your best bet is to rework your schema to support the current functionality, or use a third party tool, although that's more of a bandaid than a long term fix.

@bbinet
Copy link
Contributor

bbinet commented Sep 21, 2015

I'm also affected by this issue. See also #3552.

For now, I will try to create the third party agent @Samuel1989 is talking about to query two measurements independently and store the result into a third measurement (a kind of continuous query system outside of InfluxDB to work around this issue).

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

No branches or pull requests

5 participants