sthetland commented on a change in pull request #10848:
URL: https://github.com/apache/druid/pull/10848#discussion_r569873583
##########
File path: docs/querying/caching.md
##########
@@ -22,63 +22,61 @@ title: "Query caching"
~ under the License.
-->
+You can enable caching in Apache Druid to improve query times for
frequently-accessed data.
-Apache Druid supports query result caching at both the segment and whole-query
result level. Cache data can be stored in the
-local JVM heap or in an external distributed key/value store. In all cases,
the Druid cache is a query result cache.
-The only difference is whether the result is a _partial result_ for a
particular segment, or the result for an entire
-query. In both cases, the cache is invalidated as soon as any underlying data
changes; it will never return a stale
-result.
+When considering a caching strategy consider the following:
+- Caching enables increased concurrency on the same system, therefore leading
to noticeable performance improvements for queries on Druid clusters handling
throughput for concurrent, mixed workloads.
-Segment-level caching allows the cache to be leveraged even when some of the
underling segments are mutable and
-undergoing real-time ingestion. In this case, Druid will potentially cache
query results for immutable historical
-segments, while re-computing results for the real-time segments on each query.
Whole-query result level caching is not
-useful in this scenario, since it would be continuously invalidated.
+- If you are looking to improve response time for a single query or page load,
you should ignore caching. In general, response time for a single task should
meet performance objectives even when the cache is cold.
-Segment-level caching does require Druid to merge the per-segment results on
each query, even when they are served
-from the cache. For this reason, whole-query result level caching can be more
efficient if invalidation due to real-time
-ingestion is not an issue.
+## Cache types
+Druid supports the following types of query result caching:
+- **Segment cache** stores _partial results_ of a query for a specific segment.
+- **Whole-query cache** stores all results for a query.
-## Using and populating cache
+To avoid returning stale results, Druid invalidates a cache the moment any
underlying data changes regardless of the cache type.
-All caches have a pair of parameters that control the behavior of how
individual queries interact with the cache, a 'use' cache parameter, and a
'populate' cache parameter. These settings must be enabled at the service level
via [runtime properties](../configuration/index.md) to utilize cache, but can
be controlled on a per query basis by setting them on the [query
context](../querying/query-context.md). The 'use' parameter obviously controls
if a query will utilize cached results. The 'populate' parameter controls if a
query will update cached results. These are separate parameters to allow
queries on uncommon data to utilize cached results without polluting the cache
with results that are unlikely to be re-used by other queries, for example
large reports or very old data.
+The primary form of caching in Druid is the segment cache. The segment cache
stores query results on a per-segment basis. It is enabled on Historical
services by default.
-## Query caching on Brokers
+During query processing, the segment cache intercepts query to bypass the data
server processing threads and sends the results directly to the Broker. For
queries require minimal processing in the Broker, cached queries are very
quick. If work done on the Broker causes a query bottleneck, enabling caching
results in little noticeable query improvement.
Review comment:
```suggestion
During query processing, the segment cache intercepts the query, so that it
bypasses the data server processing threads, and sends the results directly to
the Broker. For queries requiring minimal processing in the Broker, cached
queries are very quick. If work done on the Broker causes a query bottleneck,
enabling caching results in little noticeable query improvement.
```
Not 100% sure about my edit of the first sentence here, but it's based on my
assumption that it's the query that is bypassing threads, not the segment
cache, so clarifying on that assumption.
##########
File path: docs/querying/caching.md
##########
@@ -22,63 +22,61 @@ title: "Query caching"
~ under the License.
-->
+You can enable caching in Apache Druid to improve query times for
frequently-accessed data.
Review comment:
```suggestion
You can enable caching in Apache Druid to improve query times for frequently
accessed data.
```
(the old `-ly` hyphen exemption)
##########
File path: docs/querying/using-caching.md
##########
@@ -0,0 +1,90 @@
+---
+id: using-caching
+title: "Using query caching"
+---
+
+<!--
+ ~ 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.
+ -->
+
+
+This topic covers how to configure services populate and use the Druid query
cache. For a conceptual overview and use cases, see [Query
caching](./caching.md). For information on how to configure the caching
mechanism, see [Cache
configuration](../configuration/index.md#cache-configuration).
Review comment:
```suggestion
This topic covers how to configure services to populate and use the Druid
query cache. For a conceptual overview and use cases, see [Query
caching](./caching.md). For information on how to configure the caching
mechanism, see [Cache
configuration](../configuration/index.md#cache-configuration).
```
##########
File path: docs/querying/using-caching.md
##########
@@ -0,0 +1,90 @@
+---
+id: using-caching
+title: "Using query caching"
Review comment:
just a thought: this page is now entirely config instructions, but it
appears under a "Concepts" heading in the left TOC. Not sure how much of an
issue that is -- there are other config instructions under that heading -- but
it's more apparent now with this standalone page.. We might want to rethink
that heading or page locations in the TOC, perhaps in another PR.
##########
File path: docs/querying/using-caching.md
##########
@@ -0,0 +1,90 @@
+---
+id: using-caching
+title: "Using query caching"
+---
+
+<!--
+ ~ 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.
+ -->
+
+
+This topic covers how to configure services populate and use the Druid query
cache. For a conceptual overview and use cases, see [Query
caching](./caching.md). For information on how to configure the caching
mechanism, see [Cache
configuration](../configuration/index.md#cache-configuration).
+
+All query caches have a pair of parameters that control the way individual
queries interact with the cache:
+
+- `useCache` to instruct queries to use the cached for results.
+- `populateCache` to instruct a query to cache its results.
+
+The separation of concerns, usage and population, lets you include cached
results for queries on uncommon data without polluting the cache with results
that are unlikely to be reused by other queries, for example large reports or
queries on very old data.
+
+To use caching, you must first enable the settings for a service in the
runtime properties. Afterward, you can control which queries use the cache or
populate the cache on a per-query basis within the query context.
+
+The query context settings do not override the server settings. For example,
it is possible to set a query context to use the cache, but if it is not
enabled at the service level, there's no cache to use.
+
+## Enabling query caching on Brokers
+Brokers support both segment-level and whole-query result level caching.
+
+To control **segment caching** on the Broker, set the `useCache` and
`populateCache`runtime properties. For example, to set the Broker to both use
and populate the segment cache for queries:
+```
+druid.broker.cache.useCache=true
+druid.broker.cache.populateCache=true
+```
+To control **whole-query caching** on the Broker, set the`useResultLevelCache`
and `populateResultLevelCache` runtime properties. For example, to set the
Broker to both use and populate the whole-query cache for queries:
+```
+druid.broker.cache.useResultLevelCache=true
+druid.broker.cache.populateResultLevelCache=true
+```
+See [Broker caching](../configuration/index.md#broker-caching) for a
description of all available Broker cache configurations.
+
+## Enabling query caching on Historicals
+Historicals only support **segment-level** caching. To control caching on the
Historical, set the `useCache` and `populateCache` runtime properties. For
example, to set the Historical to both use and populate the segment cache for
queries:
+ ```
+ druid.broker.cache.useCache=true
+ druid.broker.cache.populateCache=true
+ ```
+See [Historical caching](../configuration/index.md#historical-caching) for a
description of all available Historical cache configurations.
+
+## Enabling query caching on task executor services
+Task executor services, the Peon or the Indexer, only support
**segment-level** caching. To control caching on a taske executor service, set
the `useCache` and `populateCache` runtime properties. For example, to set the
Peon to both use and populate the segment cache for queries:
+
+```
+druid.realtime.cache.useCache=true
+druid.realtime.cache.populateCache=true
+```
+
+See [Peon caching](configuration/index.md#peon-caching) for a description of
all available task exector service caching options.
+
+## Enabling caching in the query context
+After you enable cacheing for a service, set cache options for individual
queries in the query [context](./query-context.md). For example, you can `POST`
a Druid SQL request to the HTTP POST API and include the context as a JSON
object:
+
+```
+{
+ "query" : "SELECT COUNT(*) FROM data_source WHERE foo = 'bar' AND __time >
TIMESTAMP '2020-01-01 00:00:00'",
+ "context" : {
+ "useCache" : "true",
+ "populateCache" : "false"
+ }
+}
+```
+In this example `populateCahce` is `false` because the query references data
that is over a year old. For more information, see [Druid SQL client
APIs](./sql.html#client-apis).
+
+## Learn more
+See the following topics for more information:
+- [Query caching](./caching.md) for an overview of caching.
+- [Query context](./query-context.md)
Review comment:
For consistency, this link could use a few words of description
##########
File path: docs/querying/caching.md
##########
@@ -22,63 +22,61 @@ title: "Query caching"
~ under the License.
-->
+You can enable caching in Apache Druid to improve query times for
frequently-accessed data.
-Apache Druid supports query result caching at both the segment and whole-query
result level. Cache data can be stored in the
-local JVM heap or in an external distributed key/value store. In all cases,
the Druid cache is a query result cache.
-The only difference is whether the result is a _partial result_ for a
particular segment, or the result for an entire
-query. In both cases, the cache is invalidated as soon as any underlying data
changes; it will never return a stale
-result.
+When considering a caching strategy consider the following:
+- Caching enables increased concurrency on the same system, therefore leading
to noticeable performance improvements for queries on Druid clusters handling
throughput for concurrent, mixed workloads.
-Segment-level caching allows the cache to be leveraged even when some of the
underling segments are mutable and
-undergoing real-time ingestion. In this case, Druid will potentially cache
query results for immutable historical
-segments, while re-computing results for the real-time segments on each query.
Whole-query result level caching is not
-useful in this scenario, since it would be continuously invalidated.
+- If you are looking to improve response time for a single query or page load,
you should ignore caching. In general, response time for a single task should
meet performance objectives even when the cache is cold.
-Segment-level caching does require Druid to merge the per-segment results on
each query, even when they are served
-from the cache. For this reason, whole-query result level caching can be more
efficient if invalidation due to real-time
-ingestion is not an issue.
+## Cache types
+Druid supports the following types of query result caching:
+- **Segment cache** stores _partial results_ of a query for a specific segment.
+- **Whole-query cache** stores all results for a query.
-## Using and populating cache
+To avoid returning stale results, Druid invalidates a cache the moment any
underlying data changes regardless of the cache type.
-All caches have a pair of parameters that control the behavior of how
individual queries interact with the cache, a 'use' cache parameter, and a
'populate' cache parameter. These settings must be enabled at the service level
via [runtime properties](../configuration/index.md) to utilize cache, but can
be controlled on a per query basis by setting them on the [query
context](../querying/query-context.md). The 'use' parameter obviously controls
if a query will utilize cached results. The 'populate' parameter controls if a
query will update cached results. These are separate parameters to allow
queries on uncommon data to utilize cached results without polluting the cache
with results that are unlikely to be re-used by other queries, for example
large reports or very old data.
+The primary form of caching in Druid is the segment cache. The segment cache
stores query results on a per-segment basis. It is enabled on Historical
services by default.
-## Query caching on Brokers
+During query processing, the segment cache intercepts query to bypass the data
server processing threads and sends the results directly to the Broker. For
queries require minimal processing in the Broker, cached queries are very
quick. If work done on the Broker causes a query bottleneck, enabling caching
results in little noticeable query improvement.
-Brokers support both segment-level and whole-query result level caching.
Segment-level caching is controlled by the
-parameters `useCache` and `populateCache`. Whole-query result level caching is
controlled by the parameters
-`useResultLevelCache` and `populateResultLevelCache` and [runtime
properties](../configuration/index.md)
-`druid.broker.cache.*`.
+The largest performance gains from caching tend to apply to `topN` and time
series queries. The impact is less for `groupBy` queries. The same applies to
queries with or without joins.
-Enabling segment-level caching on the Broker can yield faster results than if
query caches were enabled on Historicals for small
-clusters. This is the recommended setup for smaller production clusters (< 5
servers). Populating segment-level caches on
-the Broker is _not_ recommended for large production clusters, since when the
property `druid.broker.cache.populateCache` is
-set to `true` (and query context parameter `populateCache` is _not_ set to
`false`), results from Historicals are returned
-on a per segment basis, and Historicals will not be able to do any local
result merging. This impairs the ability of the
-Druid cluster to scale well.
+If you're unfamiliar with Druid architecture, review the following topics
before proceeding with caching:
Review comment:
These next three links seem like they would go better at the end of the
intro section, rather than here where it's already gotten into the page topic.
Also, the same links are repeated at the end. I would probably just have them
once, either at the end of the intro section or as they are at the end, as a
more info section.
##########
File path: docs/querying/using-caching.md
##########
@@ -0,0 +1,90 @@
+---
+id: using-caching
+title: "Using query caching"
+---
+
+<!--
+ ~ 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.
+ -->
+
+
+This topic covers how to configure services populate and use the Druid query
cache. For a conceptual overview and use cases, see [Query
caching](./caching.md). For information on how to configure the caching
mechanism, see [Cache
configuration](../configuration/index.md#cache-configuration).
+
+All query caches have a pair of parameters that control the way individual
queries interact with the cache:
+
+- `useCache` to instruct queries to use the cached for results.
+- `populateCache` to instruct a query to cache its results.
+
+The separation of concerns, usage and population, lets you include cached
results for queries on uncommon data without polluting the cache with results
that are unlikely to be reused by other queries, for example large reports or
queries on very old data.
+
+To use caching, you must first enable the settings for a service in the
runtime properties. Afterward, you can control which queries use the cache or
populate the cache on a per-query basis within the query context.
+
+The query context settings do not override the server settings. For example,
it is possible to set a query context to use the cache, but if it is not
enabled at the service level, there's no cache to use.
+
+## Enabling query caching on Brokers
+Brokers support both segment-level and whole-query result level caching.
+
+To control **segment caching** on the Broker, set the `useCache` and
`populateCache`runtime properties. For example, to set the Broker to both use
and populate the segment cache for queries:
Review comment:
```suggestion
To control **segment caching** on the Broker, set the `useCache` and
`populateCache`runtime properties. For example, to set the Broker to use and
populate the segment cache for queries:
```
##########
File path: docs/querying/caching.md
##########
@@ -22,63 +22,61 @@ title: "Query caching"
~ under the License.
-->
+You can enable caching in Apache Druid to improve query times for
frequently-accessed data.
-Apache Druid supports query result caching at both the segment and whole-query
result level. Cache data can be stored in the
-local JVM heap or in an external distributed key/value store. In all cases,
the Druid cache is a query result cache.
-The only difference is whether the result is a _partial result_ for a
particular segment, or the result for an entire
-query. In both cases, the cache is invalidated as soon as any underlying data
changes; it will never return a stale
-result.
+When considering a caching strategy consider the following:
+- Caching enables increased concurrency on the same system, therefore leading
to noticeable performance improvements for queries on Druid clusters handling
throughput for concurrent, mixed workloads.
-Segment-level caching allows the cache to be leveraged even when some of the
underling segments are mutable and
-undergoing real-time ingestion. In this case, Druid will potentially cache
query results for immutable historical
-segments, while re-computing results for the real-time segments on each query.
Whole-query result level caching is not
-useful in this scenario, since it would be continuously invalidated.
+- If you are looking to improve response time for a single query or page load,
you should ignore caching. In general, response time for a single task should
meet performance objectives even when the cache is cold.
-Segment-level caching does require Druid to merge the per-segment results on
each query, even when they are served
-from the cache. For this reason, whole-query result level caching can be more
efficient if invalidation due to real-time
-ingestion is not an issue.
+## Cache types
+Druid supports the following types of query result caching:
+- **Segment cache** stores _partial results_ of a query for a specific segment.
+- **Whole-query cache** stores all results for a query.
-## Using and populating cache
+To avoid returning stale results, Druid invalidates a cache the moment any
underlying data changes regardless of the cache type.
-All caches have a pair of parameters that control the behavior of how
individual queries interact with the cache, a 'use' cache parameter, and a
'populate' cache parameter. These settings must be enabled at the service level
via [runtime properties](../configuration/index.md) to utilize cache, but can
be controlled on a per query basis by setting them on the [query
context](../querying/query-context.md). The 'use' parameter obviously controls
if a query will utilize cached results. The 'populate' parameter controls if a
query will update cached results. These are separate parameters to allow
queries on uncommon data to utilize cached results without polluting the cache
with results that are unlikely to be re-used by other queries, for example
large reports or very old data.
+The primary form of caching in Druid is the segment cache. The segment cache
stores query results on a per-segment basis. It is enabled on Historical
services by default.
-## Query caching on Brokers
+During query processing, the segment cache intercepts query to bypass the data
server processing threads and sends the results directly to the Broker. For
queries require minimal processing in the Broker, cached queries are very
quick. If work done on the Broker causes a query bottleneck, enabling caching
results in little noticeable query improvement.
-Brokers support both segment-level and whole-query result level caching.
Segment-level caching is controlled by the
-parameters `useCache` and `populateCache`. Whole-query result level caching is
controlled by the parameters
-`useResultLevelCache` and `populateResultLevelCache` and [runtime
properties](../configuration/index.md)
-`druid.broker.cache.*`.
+The largest performance gains from caching tend to apply to `topN` and time
series queries. The impact is less for `groupBy` queries. The same applies to
queries with or without joins.
-Enabling segment-level caching on the Broker can yield faster results than if
query caches were enabled on Historicals for small
-clusters. This is the recommended setup for smaller production clusters (< 5
servers). Populating segment-level caches on
-the Broker is _not_ recommended for large production clusters, since when the
property `druid.broker.cache.populateCache` is
-set to `true` (and query context parameter `populateCache` is _not_ set to
`false`), results from Historicals are returned
-on a per segment basis, and Historicals will not be able to do any local
result merging. This impairs the ability of the
-Druid cluster to scale well.
+If you're unfamiliar with Druid architecture, review the following topics
before proceeding with caching:
+- [Druid Design](../design/architecture.md)
+- [Segments](../design/segments.md)
-## Query caching on Historicals
+To learn how to configure and use caching see [Using query
caching](./using-caching.md).
-Historicals only support segment-level caching. Segment-level caching is
controlled by the query context
-parameters `useCache` and `populateCache` and [runtime
properties](../configuration/index.md)
-`druid.historical.cache.*`.
+## Choosing a cache type
-Larger production clusters should enable segment-level cache population on
Historicals only (not on Brokers) to avoid
-having to use Brokers to merge all query results. Enabling cache population on
the Historicals instead of the Brokers
-enables the Historicals to do their own local result merging and puts less
strain on the Brokers.
+When your queries include data from segments that are mutable and undergoing
real-time ingestion, use a **segment cache**. In this case Druid caches query
results for immutable historical segments when possible. It re-computes results
for the real-time segments at query time.
-## Query caching on Ingestion Tasks
+For example, you have queries that frequently include incoming data from a
Kafka or Kinesis stream alongside unchanging segments. Whole-query caching is
not helpful in this scenario because the new data from real-time ingestion
continually invalidates the cache. Segment caching lets Druid cache results
from older immutable segments and merge them with updated data.
-Task executor processes such as the Peon or the experimental Indexer only
support segment-level caching. Segment-level
-caching is controlled by the query context parameters `useCache` and
`populateCache`
-and [runtime properties](../configuration/index.md) `druid.realtime.cache.*`.
+Segment caching requires Druid to merge the per-segment results for each
query, even when the results are cached. If real-time ingestion invalidating
the cache is not an issue for your queries, you can use **whole-query caching**
to increase query efficiency. For instance, whole-query caching is a good
option when you have queries that include data from a batch ingestion task that
runs every few hours or once a day.
+
+## Where to enable caching
+
+**Segment cache** is available as follows:
+- On Brokers and on Historicals both for small
Review comment:
```suggestion
- On both Brokers and Historicals for small
```
##########
File path: docs/querying/caching.md
##########
@@ -22,63 +22,61 @@ title: "Query caching"
~ under the License.
-->
+You can enable caching in Apache Druid to improve query times for
frequently-accessed data.
-Apache Druid supports query result caching at both the segment and whole-query
result level. Cache data can be stored in the
-local JVM heap or in an external distributed key/value store. In all cases,
the Druid cache is a query result cache.
-The only difference is whether the result is a _partial result_ for a
particular segment, or the result for an entire
-query. In both cases, the cache is invalidated as soon as any underlying data
changes; it will never return a stale
-result.
+When considering a caching strategy consider the following:
+- Caching enables increased concurrency on the same system, therefore leading
to noticeable performance improvements for queries on Druid clusters handling
throughput for concurrent, mixed workloads.
-Segment-level caching allows the cache to be leveraged even when some of the
underling segments are mutable and
-undergoing real-time ingestion. In this case, Druid will potentially cache
query results for immutable historical
-segments, while re-computing results for the real-time segments on each query.
Whole-query result level caching is not
-useful in this scenario, since it would be continuously invalidated.
+- If you are looking to improve response time for a single query or page load,
you should ignore caching. In general, response time for a single task should
meet performance objectives even when the cache is cold.
-Segment-level caching does require Druid to merge the per-segment results on
each query, even when they are served
-from the cache. For this reason, whole-query result level caching can be more
efficient if invalidation due to real-time
-ingestion is not an issue.
+## Cache types
+Druid supports the following types of query result caching:
+- **Segment cache** stores _partial results_ of a query for a specific segment.
+- **Whole-query cache** stores all results for a query.
-## Using and populating cache
+To avoid returning stale results, Druid invalidates a cache the moment any
underlying data changes regardless of the cache type.
-All caches have a pair of parameters that control the behavior of how
individual queries interact with the cache, a 'use' cache parameter, and a
'populate' cache parameter. These settings must be enabled at the service level
via [runtime properties](../configuration/index.md) to utilize cache, but can
be controlled on a per query basis by setting them on the [query
context](../querying/query-context.md). The 'use' parameter obviously controls
if a query will utilize cached results. The 'populate' parameter controls if a
query will update cached results. These are separate parameters to allow
queries on uncommon data to utilize cached results without polluting the cache
with results that are unlikely to be re-used by other queries, for example
large reports or very old data.
+The primary form of caching in Druid is the segment cache. The segment cache
stores query results on a per-segment basis. It is enabled on Historical
services by default.
-## Query caching on Brokers
+During query processing, the segment cache intercepts query to bypass the data
server processing threads and sends the results directly to the Broker. For
queries require minimal processing in the Broker, cached queries are very
quick. If work done on the Broker causes a query bottleneck, enabling caching
results in little noticeable query improvement.
-Brokers support both segment-level and whole-query result level caching.
Segment-level caching is controlled by the
-parameters `useCache` and `populateCache`. Whole-query result level caching is
controlled by the parameters
-`useResultLevelCache` and `populateResultLevelCache` and [runtime
properties](../configuration/index.md)
-`druid.broker.cache.*`.
+The largest performance gains from caching tend to apply to `topN` and time
series queries. The impact is less for `groupBy` queries. The same applies to
queries with or without joins.
-Enabling segment-level caching on the Broker can yield faster results than if
query caches were enabled on Historicals for small
-clusters. This is the recommended setup for smaller production clusters (< 5
servers). Populating segment-level caches on
-the Broker is _not_ recommended for large production clusters, since when the
property `druid.broker.cache.populateCache` is
-set to `true` (and query context parameter `populateCache` is _not_ set to
`false`), results from Historicals are returned
-on a per segment basis, and Historicals will not be able to do any local
result merging. This impairs the ability of the
-Druid cluster to scale well.
+If you're unfamiliar with Druid architecture, review the following topics
before proceeding with caching:
+- [Druid Design](../design/architecture.md)
+- [Segments](../design/segments.md)
-## Query caching on Historicals
+To learn how to configure and use caching see [Using query
caching](./using-caching.md).
-Historicals only support segment-level caching. Segment-level caching is
controlled by the query context
-parameters `useCache` and `populateCache` and [runtime
properties](../configuration/index.md)
-`druid.historical.cache.*`.
+## Choosing a cache type
-Larger production clusters should enable segment-level cache population on
Historicals only (not on Brokers) to avoid
-having to use Brokers to merge all query results. Enabling cache population on
the Historicals instead of the Brokers
-enables the Historicals to do their own local result merging and puts less
strain on the Brokers.
+When your queries include data from segments that are mutable and undergoing
real-time ingestion, use a **segment cache**. In this case Druid caches query
results for immutable historical segments when possible. It re-computes results
for the real-time segments at query time.
-## Query caching on Ingestion Tasks
+For example, you have queries that frequently include incoming data from a
Kafka or Kinesis stream alongside unchanging segments. Whole-query caching is
not helpful in this scenario because the new data from real-time ingestion
continually invalidates the cache. Segment caching lets Druid cache results
from older immutable segments and merge them with updated data.
-Task executor processes such as the Peon or the experimental Indexer only
support segment-level caching. Segment-level
-caching is controlled by the query context parameters `useCache` and
`populateCache`
-and [runtime properties](../configuration/index.md) `druid.realtime.cache.*`.
+Segment caching requires Druid to merge the per-segment results for each
query, even when the results are cached. If real-time ingestion invalidating
the cache is not an issue for your queries, you can use **whole-query caching**
to increase query efficiency. For instance, whole-query caching is a good
option when you have queries that include data from a batch ingestion task that
runs every few hours or once a day.
+
+## Where to enable caching
+
+**Segment cache** is available as follows:
+- On Brokers and on Historicals both for small
+clusters. Use this configuration for smaller production clusters (< 5
servers).
+
+ Do not use segment caches on the Broker for large production clusters.
When `druid.broker.cache.populateCache` is `true` and query context parameter
`populateCache` _is not_ `false`, Historicals return results on a per-segment
basis without merging results locally thus negatively impacting cluster
scalability.
+
+- On Historicals only, the default. Enable segment-level cache population on
Historicals only for larger production clusters to prevent Brokers having to
merge all query results. When you enable cache population on Historicals
instead of Brokers, the Historicals merge their own local results and put less
strain on the Brokers.
Review comment:
```suggestion
- On Historicals only, the default. Enable segment-level cache population on
Historicals only for larger production clusters to prevent Brokers from having
to merge all query results. When you enable cache population on Historicals
instead of Brokers, the Historicals merge their own local results and put less
strain on the Brokers.
```
##########
File path: docs/querying/caching.md
##########
@@ -22,63 +22,61 @@ title: "Query caching"
~ under the License.
-->
+You can enable caching in Apache Druid to improve query times for
frequently-accessed data.
-Apache Druid supports query result caching at both the segment and whole-query
result level. Cache data can be stored in the
-local JVM heap or in an external distributed key/value store. In all cases,
the Druid cache is a query result cache.
-The only difference is whether the result is a _partial result_ for a
particular segment, or the result for an entire
-query. In both cases, the cache is invalidated as soon as any underlying data
changes; it will never return a stale
-result.
+When considering a caching strategy consider the following:
+- Caching enables increased concurrency on the same system, therefore leading
to noticeable performance improvements for queries on Druid clusters handling
throughput for concurrent, mixed workloads.
-Segment-level caching allows the cache to be leveraged even when some of the
underling segments are mutable and
-undergoing real-time ingestion. In this case, Druid will potentially cache
query results for immutable historical
-segments, while re-computing results for the real-time segments on each query.
Whole-query result level caching is not
-useful in this scenario, since it would be continuously invalidated.
+- If you are looking to improve response time for a single query or page load,
you should ignore caching. In general, response time for a single task should
meet performance objectives even when the cache is cold.
-Segment-level caching does require Druid to merge the per-segment results on
each query, even when they are served
-from the cache. For this reason, whole-query result level caching can be more
efficient if invalidation due to real-time
-ingestion is not an issue.
+## Cache types
+Druid supports the following types of query result caching:
+- **Segment cache** stores _partial results_ of a query for a specific segment.
+- **Whole-query cache** stores all results for a query.
-## Using and populating cache
+To avoid returning stale results, Druid invalidates a cache the moment any
underlying data changes regardless of the cache type.
-All caches have a pair of parameters that control the behavior of how
individual queries interact with the cache, a 'use' cache parameter, and a
'populate' cache parameter. These settings must be enabled at the service level
via [runtime properties](../configuration/index.md) to utilize cache, but can
be controlled on a per query basis by setting them on the [query
context](../querying/query-context.md). The 'use' parameter obviously controls
if a query will utilize cached results. The 'populate' parameter controls if a
query will update cached results. These are separate parameters to allow
queries on uncommon data to utilize cached results without polluting the cache
with results that are unlikely to be re-used by other queries, for example
large reports or very old data.
+The primary form of caching in Druid is the segment cache. The segment cache
stores query results on a per-segment basis. It is enabled on Historical
services by default.
-## Query caching on Brokers
+During query processing, the segment cache intercepts query to bypass the data
server processing threads and sends the results directly to the Broker. For
queries require minimal processing in the Broker, cached queries are very
quick. If work done on the Broker causes a query bottleneck, enabling caching
results in little noticeable query improvement.
-Brokers support both segment-level and whole-query result level caching.
Segment-level caching is controlled by the
-parameters `useCache` and `populateCache`. Whole-query result level caching is
controlled by the parameters
-`useResultLevelCache` and `populateResultLevelCache` and [runtime
properties](../configuration/index.md)
-`druid.broker.cache.*`.
+The largest performance gains from caching tend to apply to `topN` and time
series queries. The impact is less for `groupBy` queries. The same applies to
queries with or without joins.
-Enabling segment-level caching on the Broker can yield faster results than if
query caches were enabled on Historicals for small
-clusters. This is the recommended setup for smaller production clusters (< 5
servers). Populating segment-level caches on
-the Broker is _not_ recommended for large production clusters, since when the
property `druid.broker.cache.populateCache` is
-set to `true` (and query context parameter `populateCache` is _not_ set to
`false`), results from Historicals are returned
-on a per segment basis, and Historicals will not be able to do any local
result merging. This impairs the ability of the
-Druid cluster to scale well.
+If you're unfamiliar with Druid architecture, review the following topics
before proceeding with caching:
+- [Druid Design](../design/architecture.md)
+- [Segments](../design/segments.md)
-## Query caching on Historicals
+To learn how to configure and use caching see [Using query
caching](./using-caching.md).
-Historicals only support segment-level caching. Segment-level caching is
controlled by the query context
-parameters `useCache` and `populateCache` and [runtime
properties](../configuration/index.md)
-`druid.historical.cache.*`.
+## Choosing a cache type
-Larger production clusters should enable segment-level cache population on
Historicals only (not on Brokers) to avoid
-having to use Brokers to merge all query results. Enabling cache population on
the Historicals instead of the Brokers
-enables the Historicals to do their own local result merging and puts less
strain on the Brokers.
+When your queries include data from segments that are mutable and undergoing
real-time ingestion, use a **segment cache**. In this case Druid caches query
results for immutable historical segments when possible. It re-computes results
for the real-time segments at query time.
-## Query caching on Ingestion Tasks
+For example, you have queries that frequently include incoming data from a
Kafka or Kinesis stream alongside unchanging segments. Whole-query caching is
not helpful in this scenario because the new data from real-time ingestion
continually invalidates the cache. Segment caching lets Druid cache results
from older immutable segments and merge them with updated data.
-Task executor processes such as the Peon or the experimental Indexer only
support segment-level caching. Segment-level
-caching is controlled by the query context parameters `useCache` and
`populateCache`
-and [runtime properties](../configuration/index.md) `druid.realtime.cache.*`.
+Segment caching requires Druid to merge the per-segment results for each
query, even when the results are cached. If real-time ingestion invalidating
the cache is not an issue for your queries, you can use **whole-query caching**
to increase query efficiency. For instance, whole-query caching is a good
option when you have queries that include data from a batch ingestion task that
runs every few hours or once a day.
+
+## Where to enable caching
+
+**Segment cache** is available as follows:
+- On Brokers and on Historicals both for small
+clusters. Use this configuration for smaller production clusters (< 5
servers).
+
+ Do not use segment caches on the Broker for large production clusters.
When `druid.broker.cache.populateCache` is `true` and query context parameter
`populateCache` _is not_ `false`, Historicals return results on a per-segment
basis without merging results locally thus negatively impacting cluster
scalability.
+
+- On Historicals only, the default. Enable segment-level cache population on
Historicals only for larger production clusters to prevent Brokers having to
merge all query results. When you enable cache population on Historicals
instead of Brokers, the Historicals merge their own local results and put less
strain on the Brokers.
+
+- On ingestion tasks in the Peon or Indexer service only. Larger production
clusters should enable segment-level cache population on task execution
services only to prevent Brokers having to merge all query results. When you
enable cache population on task execution services instead of Brokers, the the
task execution services to merge their own local results and put less strain on
the brokers.
Review comment:
```suggestion
- On ingestion tasks in the Peon or Indexer service only. Larger production
clusters should enable segment-level cache population on task execution
services only to prevent Brokers having to merge all query results. When you
enable cache population on task execution services instead of Brokers, the task
execution services merge their own local results, putting less strain on the
brokers.
```
##########
File path: docs/querying/caching.md
##########
@@ -1,5 +1,5 @@
---
-id: caching
+id: using-caching
Review comment:
I think this was an unintentional change? This is the same ID value as
the next file, which may be why this page doesn't appear in the sidebar TOC.
(It might need to be added to sidebars.json as well)
```suggestion
id: caching
```
##########
File path: docs/querying/using-caching.md
##########
@@ -0,0 +1,90 @@
+---
+id: using-caching
+title: "Using query caching"
+---
+
+<!--
+ ~ 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.
+ -->
+
+
+This topic covers how to configure services populate and use the Druid query
cache. For a conceptual overview and use cases, see [Query
caching](./caching.md). For information on how to configure the caching
mechanism, see [Cache
configuration](../configuration/index.md#cache-configuration).
+
+All query caches have a pair of parameters that control the way individual
queries interact with the cache:
+
+- `useCache` to instruct queries to use the cached for results.
+- `populateCache` to instruct a query to cache its results.
+
+The separation of concerns, usage and population, lets you include cached
results for queries on uncommon data without polluting the cache with results
that are unlikely to be reused by other queries, for example large reports or
queries on very old data.
+
+To use caching, you must first enable the settings for a service in the
runtime properties. Afterward, you can control which queries use the cache or
populate the cache on a per-query basis within the query context.
+
+The query context settings do not override the server settings. For example,
it is possible to set a query context to use the cache, but if it is not
enabled at the service level, there's no cache to use.
+
+## Enabling query caching on Brokers
+Brokers support both segment-level and whole-query result level caching.
+
+To control **segment caching** on the Broker, set the `useCache` and
`populateCache`runtime properties. For example, to set the Broker to both use
and populate the segment cache for queries:
+```
+druid.broker.cache.useCache=true
+druid.broker.cache.populateCache=true
+```
+To control **whole-query caching** on the Broker, set the`useResultLevelCache`
and `populateResultLevelCache` runtime properties. For example, to set the
Broker to both use and populate the whole-query cache for queries:
+```
+druid.broker.cache.useResultLevelCache=true
+druid.broker.cache.populateResultLevelCache=true
+```
+See [Broker caching](../configuration/index.md#broker-caching) for a
description of all available Broker cache configurations.
+
+## Enabling query caching on Historicals
+Historicals only support **segment-level** caching. To control caching on the
Historical, set the `useCache` and `populateCache` runtime properties. For
example, to set the Historical to both use and populate the segment cache for
queries:
+ ```
+ druid.broker.cache.useCache=true
+ druid.broker.cache.populateCache=true
+ ```
+See [Historical caching](../configuration/index.md#historical-caching) for a
description of all available Historical cache configurations.
+
+## Enabling query caching on task executor services
+Task executor services, the Peon or the Indexer, only support
**segment-level** caching. To control caching on a taske executor service, set
the `useCache` and `populateCache` runtime properties. For example, to set the
Peon to both use and populate the segment cache for queries:
+
+```
+druid.realtime.cache.useCache=true
+druid.realtime.cache.populateCache=true
+```
+
+See [Peon caching](configuration/index.md#peon-caching) for a description of
all available task exector service caching options.
+
+## Enabling caching in the query context
+After you enable cacheing for a service, set cache options for individual
queries in the query [context](./query-context.md). For example, you can `POST`
a Druid SQL request to the HTTP POST API and include the context as a JSON
object:
+
+```
+{
+ "query" : "SELECT COUNT(*) FROM data_source WHERE foo = 'bar' AND __time >
TIMESTAMP '2020-01-01 00:00:00'",
+ "context" : {
+ "useCache" : "true",
+ "populateCache" : "false"
+ }
+}
+```
+In this example `populateCahce` is `false` because the query references data
that is over a year old. For more information, see [Druid SQL client
APIs](./sql.html#client-apis).
Review comment:
```suggestion
In this example `populateCache` is `false` because the query references data
that is over a year old. For more information, see [Druid SQL client
APIs](./sql.md#client-apis).
```
##########
File path: docs/querying/using-caching.md
##########
@@ -0,0 +1,90 @@
+---
+id: using-caching
+title: "Using query caching"
+---
+
+<!--
+ ~ 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.
+ -->
+
+
+This topic covers how to configure services populate and use the Druid query
cache. For a conceptual overview and use cases, see [Query
caching](./caching.md). For information on how to configure the caching
mechanism, see [Cache
configuration](../configuration/index.md#cache-configuration).
+
+All query caches have a pair of parameters that control the way individual
queries interact with the cache:
+
+- `useCache` to instruct queries to use the cached for results.
+- `populateCache` to instruct a query to cache its results.
+
+The separation of concerns, usage and population, lets you include cached
results for queries on uncommon data without polluting the cache with results
that are unlikely to be reused by other queries, for example large reports or
queries on very old data.
+
+To use caching, you must first enable the settings for a service in the
runtime properties. Afterward, you can control which queries use the cache or
populate the cache on a per-query basis within the query context.
+
+The query context settings do not override the server settings. For example,
it is possible to set a query context to use the cache, but if it is not
enabled at the service level, there's no cache to use.
+
+## Enabling query caching on Brokers
+Brokers support both segment-level and whole-query result level caching.
+
+To control **segment caching** on the Broker, set the `useCache` and
`populateCache`runtime properties. For example, to set the Broker to both use
and populate the segment cache for queries:
+```
+druid.broker.cache.useCache=true
+druid.broker.cache.populateCache=true
+```
+To control **whole-query caching** on the Broker, set the`useResultLevelCache`
and `populateResultLevelCache` runtime properties. For example, to set the
Broker to both use and populate the whole-query cache for queries:
+```
+druid.broker.cache.useResultLevelCache=true
+druid.broker.cache.populateResultLevelCache=true
+```
+See [Broker caching](../configuration/index.md#broker-caching) for a
description of all available Broker cache configurations.
+
+## Enabling query caching on Historicals
+Historicals only support **segment-level** caching. To control caching on the
Historical, set the `useCache` and `populateCache` runtime properties. For
example, to set the Historical to both use and populate the segment cache for
queries:
+ ```
+ druid.broker.cache.useCache=true
+ druid.broker.cache.populateCache=true
+ ```
+See [Historical caching](../configuration/index.md#historical-caching) for a
description of all available Historical cache configurations.
+
+## Enabling query caching on task executor services
+Task executor services, the Peon or the Indexer, only support
**segment-level** caching. To control caching on a taske executor service, set
the `useCache` and `populateCache` runtime properties. For example, to set the
Peon to both use and populate the segment cache for queries:
Review comment:
```suggestion
Task executor services, the Peon or the Indexer, only support
**segment-level** caching. To control caching on a task executor service, set
the `useCache` and `populateCache` runtime properties. For example, to set the
Peon to use and populate the segment cache for queries:
```
##########
File path: docs/querying/using-caching.md
##########
@@ -0,0 +1,90 @@
+---
+id: using-caching
+title: "Using query caching"
+---
+
+<!--
+ ~ 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.
+ -->
+
+
+This topic covers how to configure services populate and use the Druid query
cache. For a conceptual overview and use cases, see [Query
caching](./caching.md). For information on how to configure the caching
mechanism, see [Cache
configuration](../configuration/index.md#cache-configuration).
+
+All query caches have a pair of parameters that control the way individual
queries interact with the cache:
+
+- `useCache` to instruct queries to use the cached for results.
+- `populateCache` to instruct a query to cache its results.
+
+The separation of concerns, usage and population, lets you include cached
results for queries on uncommon data without polluting the cache with results
that are unlikely to be reused by other queries, for example large reports or
queries on very old data.
Review comment:
```suggestion
The separation of concerns, usage and population, lets you include cached
results for queries on uncommon data without polluting the cache with results
that are unlikely to be reused by other queries, for example, large reports or
queries on very old data.
```
##########
File path: docs/querying/using-caching.md
##########
@@ -0,0 +1,90 @@
+---
+id: using-caching
+title: "Using query caching"
+---
+
+<!--
+ ~ 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.
+ -->
+
+
+This topic covers how to configure services populate and use the Druid query
cache. For a conceptual overview and use cases, see [Query
caching](./caching.md). For information on how to configure the caching
mechanism, see [Cache
configuration](../configuration/index.md#cache-configuration).
+
+All query caches have a pair of parameters that control the way individual
queries interact with the cache:
+
+- `useCache` to instruct queries to use the cached for results.
+- `populateCache` to instruct a query to cache its results.
+
+The separation of concerns, usage and population, lets you include cached
results for queries on uncommon data without polluting the cache with results
that are unlikely to be reused by other queries, for example large reports or
queries on very old data.
+
+To use caching, you must first enable the settings for a service in the
runtime properties. Afterward, you can control which queries use the cache or
populate the cache on a per-query basis within the query context.
+
+The query context settings do not override the server settings. For example,
it is possible to set a query context to use the cache, but if it is not
enabled at the service level, there's no cache to use.
+
+## Enabling query caching on Brokers
+Brokers support both segment-level and whole-query result level caching.
+
+To control **segment caching** on the Broker, set the `useCache` and
`populateCache`runtime properties. For example, to set the Broker to both use
and populate the segment cache for queries:
+```
+druid.broker.cache.useCache=true
+druid.broker.cache.populateCache=true
+```
+To control **whole-query caching** on the Broker, set the`useResultLevelCache`
and `populateResultLevelCache` runtime properties. For example, to set the
Broker to both use and populate the whole-query cache for queries:
+```
+druid.broker.cache.useResultLevelCache=true
+druid.broker.cache.populateResultLevelCache=true
+```
+See [Broker caching](../configuration/index.md#broker-caching) for a
description of all available Broker cache configurations.
+
+## Enabling query caching on Historicals
+Historicals only support **segment-level** caching. To control caching on the
Historical, set the `useCache` and `populateCache` runtime properties. For
example, to set the Historical to both use and populate the segment cache for
queries:
+ ```
+ druid.broker.cache.useCache=true
+ druid.broker.cache.populateCache=true
+ ```
+See [Historical caching](../configuration/index.md#historical-caching) for a
description of all available Historical cache configurations.
+
+## Enabling query caching on task executor services
+Task executor services, the Peon or the Indexer, only support
**segment-level** caching. To control caching on a taske executor service, set
the `useCache` and `populateCache` runtime properties. For example, to set the
Peon to both use and populate the segment cache for queries:
+
+```
+druid.realtime.cache.useCache=true
+druid.realtime.cache.populateCache=true
+```
+
+See [Peon caching](configuration/index.md#peon-caching) for a description of
all available task exector service caching options.
Review comment:
```suggestion
See [Peon caching](configuration/index.md#peon-caching) for a description of
all available task executor service caching options.
```
##########
File path: docs/querying/using-caching.md
##########
@@ -0,0 +1,90 @@
+---
+id: using-caching
+title: "Using query caching"
+---
+
+<!--
+ ~ 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.
+ -->
+
+
+This topic covers how to configure services populate and use the Druid query
cache. For a conceptual overview and use cases, see [Query
caching](./caching.md). For information on how to configure the caching
mechanism, see [Cache
configuration](../configuration/index.md#cache-configuration).
+
+All query caches have a pair of parameters that control the way individual
queries interact with the cache:
+
+- `useCache` to instruct queries to use the cached for results.
+- `populateCache` to instruct a query to cache its results.
+
+The separation of concerns, usage and population, lets you include cached
results for queries on uncommon data without polluting the cache with results
that are unlikely to be reused by other queries, for example large reports or
queries on very old data.
+
+To use caching, you must first enable the settings for a service in the
runtime properties. Afterward, you can control which queries use the cache or
populate the cache on a per-query basis within the query context.
+
+The query context settings do not override the server settings. For example,
it is possible to set a query context to use the cache, but if it is not
enabled at the service level, there's no cache to use.
+
+## Enabling query caching on Brokers
+Brokers support both segment-level and whole-query result level caching.
+
+To control **segment caching** on the Broker, set the `useCache` and
`populateCache`runtime properties. For example, to set the Broker to both use
and populate the segment cache for queries:
+```
+druid.broker.cache.useCache=true
+druid.broker.cache.populateCache=true
+```
+To control **whole-query caching** on the Broker, set the`useResultLevelCache`
and `populateResultLevelCache` runtime properties. For example, to set the
Broker to both use and populate the whole-query cache for queries:
+```
+druid.broker.cache.useResultLevelCache=true
+druid.broker.cache.populateResultLevelCache=true
+```
+See [Broker caching](../configuration/index.md#broker-caching) for a
description of all available Broker cache configurations.
+
+## Enabling query caching on Historicals
+Historicals only support **segment-level** caching. To control caching on the
Historical, set the `useCache` and `populateCache` runtime properties. For
example, to set the Historical to both use and populate the segment cache for
queries:
+ ```
+ druid.broker.cache.useCache=true
+ druid.broker.cache.populateCache=true
+ ```
+See [Historical caching](../configuration/index.md#historical-caching) for a
description of all available Historical cache configurations.
+
+## Enabling query caching on task executor services
+Task executor services, the Peon or the Indexer, only support
**segment-level** caching. To control caching on a taske executor service, set
the `useCache` and `populateCache` runtime properties. For example, to set the
Peon to both use and populate the segment cache for queries:
+
+```
+druid.realtime.cache.useCache=true
+druid.realtime.cache.populateCache=true
+```
+
+See [Peon caching](configuration/index.md#peon-caching) for a description of
all available task exector service caching options.
+
+## Enabling caching in the query context
+After you enable cacheing for a service, set cache options for individual
queries in the query [context](./query-context.md). For example, you can `POST`
a Druid SQL request to the HTTP POST API and include the context as a JSON
object:
Review comment:
```suggestion
After you enable caching for a service, set cache options for individual
queries in the query [context](./query-context.md). For example, you can `POST`
a Druid SQL request to the HTTP POST API and include the context as a JSON
object:
```
##########
File path: docs/querying/using-caching.md
##########
@@ -0,0 +1,90 @@
+---
+id: using-caching
+title: "Using query caching"
+---
+
+<!--
+ ~ 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.
+ -->
+
+
+This topic covers how to configure services populate and use the Druid query
cache. For a conceptual overview and use cases, see [Query
caching](./caching.md). For information on how to configure the caching
mechanism, see [Cache
configuration](../configuration/index.md#cache-configuration).
+
+All query caches have a pair of parameters that control the way individual
queries interact with the cache:
+
+- `useCache` to instruct queries to use the cached for results.
+- `populateCache` to instruct a query to cache its results.
+
+The separation of concerns, usage and population, lets you include cached
results for queries on uncommon data without polluting the cache with results
that are unlikely to be reused by other queries, for example large reports or
queries on very old data.
+
+To use caching, you must first enable the settings for a service in the
runtime properties. Afterward, you can control which queries use the cache or
populate the cache on a per-query basis within the query context.
+
+The query context settings do not override the server settings. For example,
it is possible to set a query context to use the cache, but if it is not
enabled at the service level, there's no cache to use.
+
+## Enabling query caching on Brokers
+Brokers support both segment-level and whole-query result level caching.
+
+To control **segment caching** on the Broker, set the `useCache` and
`populateCache`runtime properties. For example, to set the Broker to both use
and populate the segment cache for queries:
+```
+druid.broker.cache.useCache=true
+druid.broker.cache.populateCache=true
+```
+To control **whole-query caching** on the Broker, set the`useResultLevelCache`
and `populateResultLevelCache` runtime properties. For example, to set the
Broker to both use and populate the whole-query cache for queries:
Review comment:
```suggestion
To control **whole-query caching** on the Broker, set the
`useResultLevelCache` and `populateResultLevelCache` runtime properties. For
example, to set the Broker to use and populate the whole-query cache for
queries:
```
The phrase "to both use and populate..." occurs below in the text as well.
I'd suggest removing to avoid the split infinitive... not necessarily out of
strict adherence to the rule, but just in this case it seems like "both" is not
doing enough work to warrant it.
##########
File path: docs/querying/using-caching.md
##########
@@ -0,0 +1,90 @@
+---
+id: using-caching
+title: "Using query caching"
+---
+
+<!--
+ ~ 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.
+ -->
+
+
+This topic covers how to configure services populate and use the Druid query
cache. For a conceptual overview and use cases, see [Query
caching](./caching.md). For information on how to configure the caching
mechanism, see [Cache
configuration](../configuration/index.md#cache-configuration).
+
+All query caches have a pair of parameters that control the way individual
queries interact with the cache:
+
+- `useCache` to instruct queries to use the cached for results.
Review comment:
```suggestion
- `useCache` to instruct queries to use the cache for results.
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
