3d4d9062a0
Previously, only time expressions got propagated inwards. The reason for
this was simple. If the outer query was going to filter to a specific
time range, then it would be unnecessary for the inner query to output
points within that time frame. It started as an optimization, but became
a feature because there was no reason to have the user repeat the same
time clause for the inner query as the outer query. So we allowed an
aggregate query with an interval to pass validation in the subquery if
the outer query had a time range. But `GROUP BY` clauses were not
propagated because that same logic didn't apply to them. It's not an
optimization there. So while grouping by a tag in the outer query
without grouping by it in the inner query was useless, there wasn't any
particular reason to care.
Then a bug was found where wildcards would propagate the dimensions
correctly, but the outer query containing a group by with the inner
query omitting it wouldn't correctly filter out the outer group by. We
could fix that filtering, but on further review, I had been seeing
people make that same mistake a lot. People seem to just believe that
the grouping should be propagated inwards. Instead of trying to fight
what the user wanted and explicitly erase groupings that weren't
propagated manually, we might as well just propagate them for the user
to make their lives easier. There is no useful situation where you would
want to group into buckets that can't physically exist so we might as
well do _something_ useful.
This will also now propagate time intervals to inner queries since the
same applies there. But, while the interval propagates, the following
query will not pass validation since it is still not possible to use a
grouping interval with a raw query (even if the inner query is an
aggregate):
SELECT * FROM (SELECT mean(value) FROM cpu) WHERE time > now() - 5m GROUP BY time(1m)
This also means wildcards will behave a bit differently. They will
retrieve dimensions from the sources in the inner query rather than just
using the dimensions in the group by.
Fixing top() and bottom() to return the correct auxiliary fields.
Unfortunately, we were not copying the buffer with the auxiliary fields
so those values would be overwritten by a later point.
|
||
|---|---|---|
| .github | ||
| .hooks | ||
| client | ||
| cmd | ||
| coordinator | ||
| etc | ||
| importer | ||
| influxql | ||
| internal | ||
| man | ||
| models | ||
| monitor | ||
| pkg | ||
| scripts | ||
| services | ||
| stress | ||
| tcp | ||
| tests | ||
| toml | ||
| tsdb | ||
| uuid | ||
| .dockerignore | ||
| .gitignore | ||
| .mention-bot | ||
| CHANGELOG.md | ||
| CODING_GUIDELINES.md | ||
| CONTRIBUTING.md | ||
| DOCKER.md | ||
| Dockerfile | ||
| Dockerfile_build_ubuntu32 | ||
| Dockerfile_build_ubuntu64 | ||
| Dockerfile_build_ubuntu64_git | ||
| Dockerfile_test_ubuntu32 | ||
| Godeps | ||
| LICENSE | ||
| LICENSE_OF_DEPENDENCIES.md | ||
| Makefile | ||
| QUERIES.md | ||
| README.md | ||
| TODO.md | ||
| appveyor.yml | ||
| build-docker.sh | ||
| build.py | ||
| build.sh | ||
| circle-test.sh | ||
| circle.yml | ||
| errors.go | ||
| gobuild.sh | ||
| influxdb.go | ||
| nightly.sh | ||
| node.go | ||
| package.sh | ||
| test.sh | ||
README.md
InfluxDB 
An Open-Source Time Series Database
InfluxDB is an open source time series database with no external dependencies. It's useful for recording metrics, events, and performing analytics.
Features
- Built-in HTTP API so you don't have to write any server side code to get up and running.
- Data can be tagged, allowing very flexible querying.
- SQL-like query language.
- Simple to install and manage, and fast to get data in and out.
- It aims to answer queries in real-time. That means every data point is indexed as it comes in and is immediately available in queries that should return in < 100ms.
Installation
We recommend installing InfluxDB using one of the pre-built packages. Then start InfluxDB using:
service influxdb startif you have installed InfluxDB using an official Debian or RPM package.systemctl start influxdbif you have installed InfluxDB using an official Debian or RPM package, and are running a distro withsystemd. For example, Ubuntu 15 or later.$GOPATH/bin/influxdif you have built InfluxDB from source.
Getting Started
Create your first database
curl -G 'http://localhost:8086/query' --data-urlencode "q=CREATE DATABASE mydb"
Insert some data
curl -XPOST 'http://localhost:8086/write?db=mydb' \
-d 'cpu,host=server01,region=uswest load=42 1434055562000000000'
curl -XPOST 'http://localhost:8086/write?db=mydb' \
-d 'cpu,host=server02,region=uswest load=78 1434055562000000000'
curl -XPOST 'http://localhost:8086/write?db=mydb' \
-d 'cpu,host=server03,region=useast load=15.4 1434055562000000000'
Query for the data
curl -G http://localhost:8086/query?pretty=true --data-urlencode "db=mydb" \
--data-urlencode "q=SELECT * FROM cpu WHERE host='server01' AND time < now() - 1d"
Analyze the data
curl -G http://localhost:8086/query?pretty=true --data-urlencode "db=mydb" \
--data-urlencode "q=SELECT mean(load) FROM cpu WHERE region='uswest'"
Documentation
- Read more about the design goals and motivations of the project.
- Follow the getting started guide to learn the basics in just a few minutes.
- Learn more about InfluxDB's key concepts.
Contributing
If you're feeling adventurous and want to contribute to InfluxDB, see our contributing doc for info on how to make feature requests, build from source, and run tests.
Looking for Support?
InfluxDB offers a number of services to help your project succeed. We offer Developer Support for organizations in active development, Managed Hosting to make it easy to move into production, and Enterprise Support for companies requiring the best response times, SLAs, and technical fixes. Visit our support page or contact sales@influxdb.com to learn how we can best help you succeed.