You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: guide/reference/index-modules/cache.textile
+24-2
Original file line number
Diff line number
Diff line change
@@ -9,10 +9,32 @@ p. There are different caching inner modules that correspond to an index. They i
9
9
10
10
h1. Filter Cache
11
11
12
-
p. The filter cache is responsible to cache the results of filters (used in the query). There are 3 main types of the filter cache: @soft@, @weak@, and @resident@. The type can be set using the @index.cache.filter.type@ and defaults to @soft@ (and, in general, should not be changed).
12
+
p. The filter cache is responsible to cache the results of filters (used in the query). The default implementation of a filter cache (and the one recommended to use in almost all cases) is the @node@ filter cache type.
13
+
14
+
h2. Node Filter Cache
15
+
16
+
p. The @node@ filter cache allows to configure either a percentage (of the total memory allocated to the process) or an exact value of the cache used for filter cache. All shards allocated on that node will use this cache (thats why its called @node@`), and evicted based on LRU logic.
17
+
18
+
p. The setting that allows to control the memory size for the filter cache is @indices.cache.filter.size@ and it defaults to @20%@. *Note*, this is *not* an index level setting but a node level setting (can be configured in the node configuration).
19
+
20
+
p. @indices.cache.filter.size@ can accept either a percentage value, like @30%@, or an exact value, like @512mb@.
21
+
22
+
h2. Index Filter Cache
23
+
24
+
p. A filter cache that exists on the index level (on each node). Generally, not recommended for use since its memory usage depends on which shards are allocated on each node and its hard to predict it. The types are: @resident@, @soft@ and @weak@.
13
25
14
26
p. All types support the following settings:
15
27
16
28
|_. Setting |_. Description |
17
-
|@index.cache.filter.max_size@|The max size of the cache (per search segment in a shard). Defaults to not set (@-1@), which is usually fine with @soft@ cache and proper cacheable filters.|
29
+
|@index.cache.filter.max_size@|The max size (count, not byte size) of the cache (per search segment in a shard). Defaults to not set (@-1@), which is usually fine with @soft@ cache and proper cacheable filters.|
18
30
|@index.cache.filter.expire@|A time based setting that expires filters after a certain time of inactivity. Defaults to @-1@. For example, can be set to @5m@ for a 5 minute expiry.|
31
+
32
+
h2. Field Data Cache
33
+
34
+
p. The field data cache is used mainly when sorting on or faceting on a field. It loads all the field values to memory in order to provide fast document based access to those values. The field data cache can be expensive to build for a field, so its recommended to have enough memory to allocate it, and keep it loaded.
35
+
36
+
p. The default type for the field data cache is @resident@ (because of the cost of rebuilding it). Other types include @soft@.
37
+
38
+
|_. Setting |_. Description |
39
+
|@index.cache.field.max_size@|The max size (count, not byte size) of the cache (per search segment in a shard). Defaults to not set (@-1@).|
40
+
|@index.cache.field.expire@|A time based setting that expires filters after a certain time of inactivity. Defaults to @-1@. For example, can be set to @5m@ for a 5 minute expiry.|
0 commit comments