2018-12-13 14:47:20 -05:00
---
layout: doc_page
title: "Querying"
---
2018-11-13 12:38:37 -05:00
<!--
~ Licensed to the Apache Software Foundation (ASF) under one
~ or more contributor license agreements. See the NOTICE file
~ distributed with this work for additional information
~ regarding copyright ownership. The ASF licenses this file
~ to you under the Apache License, Version 2.0 (the
~ "License"); you may not use this file except in compliance
~ with the License. You may obtain a copy of the License at
~
~ http://www.apache.org/licenses/LICENSE-2.0
~
~ Unless required by applicable law or agreed to in writing,
~ software distributed under the License is distributed on an
~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
~ KIND, either express or implied. See the License for the
~ specific language governing permissions and limitations
~ under the License.
-->
2018-09-04 15:54:41 -04:00
# Querying
2015-05-05 17:07:32 -04:00
2019-02-28 21:10:39 -05:00
Queries are made using an HTTP REST style request to queryable processes ([Broker](../design/broker.html),
2018-09-04 15:54:41 -04:00
[Historical ](../design/historical.html ). [Peons ](../design/peons.html )) that are running stream ingestion tasks can also accept queries. The
2019-02-28 21:10:39 -05:00
query is expressed in JSON and each of these process types expose the same
REST query interface. For normal Druid operations, queries should be issued to the Broker processes. Queries can be posted
to the queryable processes like this -
2016-02-28 18:41:33 -05:00
```bash
2018-10-12 17:29:14 -04:00
curl -X POST '< queryable_host > :< port > /druid/v2/?pretty' -H 'Content-Type:application/json' -H 'Accept:application/json' -d @< query_json_file >
2016-02-28 18:41:33 -05:00
```
2015-12-31 19:32:51 -05:00
Druid's native query language is JSON over HTTP, although many members of the community have contributed different
[client libraries ](../development/libraries.html ) in other languages to query Druid.
2015-05-05 17:07:32 -04:00
2018-10-12 17:29:14 -04:00
The Content-Type/Accept Headers can also take 'application/x-jackson-smile'.
```bash
2018-11-13 19:51:02 -05:00
curl -X POST '< queryable_host > :< port > /druid/v2/?pretty' -H 'Content-Type:application/json' -H 'Accept:application/x-jackson-smile' -d @< query_json_file >
2018-10-12 17:29:14 -04:00
```
Note: If Accept header is not provided, it defaults to value of 'Content-Type' header.
2015-12-31 19:32:51 -05:00
Druid's native query is relatively low level, mapping closely to how computations are performed internally. Druid queries
are designed to be lightweight and complete very quickly. This means that for more complex analysis, or to build
more complex visualizations, multiple Druid queries may be required.
2015-05-05 17:07:32 -04:00
2018-09-04 15:54:41 -04:00
## Available Queries
2015-05-05 17:07:32 -04:00
Druid has numerous query types for various use cases. Queries are composed of various JSON properties and Druid has different types of queries for different use cases. The documentation for the various query types describe all the JSON properties that can be set.
### Aggregation Queries
* [Timeseries ](../querying/timeseriesquery.html )
* [TopN ](../querying/topnquery.html )
* [GroupBy ](../querying/groupbyquery.html )
### Metadata Queries
* [Time Boundary ](../querying/timeboundaryquery.html )
* [Segment Metadata ](../querying/segmentmetadataquery.html )
* [Datasource Metadata ](../querying/datasourcemetadataquery.html )
### Search Queries
* [Search ](../querying/searchquery.html )
2018-09-04 15:54:41 -04:00
## Which Query Should I Use?
2015-05-05 17:07:32 -04:00
Where possible, we recommend using [Timeseries]() and [TopN]() queries instead of [GroupBy](). GroupBy is the most flexible Druid query, but also has the poorest performance.
Timeseries are significantly faster than groupBy queries for aggregations that don't require grouping over dimensions. For grouping and sorting over a single dimension,
topN queries are much more optimized than groupBys.
2018-09-04 15:54:41 -04:00
## Query Cancellation
2015-05-05 17:07:32 -04:00
Queries can be cancelled explicitly using their unique identifier. If the
query identifier is set at the time of query, or is otherwise known, the following
2019-01-30 22:41:07 -05:00
endpoint can be used on the Broker or Router to cancel the query.
2015-05-05 17:07:32 -04:00
```sh
DELETE /druid/v2/{queryId}
```
For example, if the query ID is `abc123` , the query can be cancelled as follows:
```sh
curl -X DELETE "http://host:port/druid/v2/abc123"
```
More useful query errors. (#3335)
Follow-up to #1773, which meant to add more useful query errors but
did not actually do so. Since that patch, any error other than
interrupt/cancel/timeout was reported as `{"error":"Unknown exception"}`.
With this patch, the error fields are:
- error, one of the specific strings "Query interrupted", "Query timeout",
"Query cancelled", or "Unknown exception" (same behavior as before).
- errorMessage, the message of the topmost non-QueryInterruptedException
in the causality chain.
- errorClass, the class of the topmost non-QueryInterruptedException
in the causality chain.
- host, the host that failed the query.
2016-08-09 04:14:52 -04:00
2018-09-04 15:54:41 -04:00
## Query Errors
More useful query errors. (#3335)
Follow-up to #1773, which meant to add more useful query errors but
did not actually do so. Since that patch, any error other than
interrupt/cancel/timeout was reported as `{"error":"Unknown exception"}`.
With this patch, the error fields are:
- error, one of the specific strings "Query interrupted", "Query timeout",
"Query cancelled", or "Unknown exception" (same behavior as before).
- errorMessage, the message of the topmost non-QueryInterruptedException
in the causality chain.
- errorClass, the class of the topmost non-QueryInterruptedException
in the causality chain.
- host, the host that failed the query.
2016-08-09 04:14:52 -04:00
If a query fails, you will get an HTTP 500 response containing a JSON object with the following structure:
```json
{
"error" : "Query timeout",
"errorMessage" : "Timeout waiting for task.",
"errorClass" : "java.util.concurrent.TimeoutException",
"host" : "druid1.example.com:8083"
}
```
The fields in the response are:
|field|description|
|-----|-----------|
|error|A well-defined error code (see below).|
|errorMessage|A free-form message with more information about the error. May be null.|
|errorClass|The class of the exception that caused this error. May be null.|
|host|The host on which this error occurred. May be null.|
Possible codes for the *error* field include:
|code|description|
|----|-----------|
|`Query timeout`|The query timed out.|
|`Query interrupted`|The query was interrupted, possibly due to JVM shutdown.|
|`Query cancelled`|The query was cancelled through the query cancellation API.|
2016-08-09 13:50:56 -04:00
|`Resource limit exceeded`|The query exceeded a configured resource limit (e.g. groupBy maxResults).|
2018-04-26 16:06:25 -04:00
|`Unauthorized request.`|The query was denied due to security policy. Either the user was not recognized, or the user was recognized but does not have access to the requested resource.|
More useful query errors. (#3335)
Follow-up to #1773, which meant to add more useful query errors but
did not actually do so. Since that patch, any error other than
interrupt/cancel/timeout was reported as `{"error":"Unknown exception"}`.
With this patch, the error fields are:
- error, one of the specific strings "Query interrupted", "Query timeout",
"Query cancelled", or "Unknown exception" (same behavior as before).
- errorMessage, the message of the topmost non-QueryInterruptedException
in the causality chain.
- errorClass, the class of the topmost non-QueryInterruptedException
in the causality chain.
- host, the host that failed the query.
2016-08-09 04:14:52 -04:00
|`Unknown exception`|Some other exception occurred. Check errorMessage and errorClass for details, although keep in mind that the contents of those fields are free-form and may change from release to release.|