@@ -33,6 +33,7 @@ according to your performance, resiliency and data retention requirements.
33
33
[[content-tier]]
34
34
=== Content tier
35
35
36
+ // tag::content-tier[]
36
37
Data stored in the content tier is generally a collection of items such as a product catalog or article archive.
37
38
Unlike time series data, the value of the content remains relatively constant over time,
38
39
so it doesn't make sense to move it to a tier with different performance characteristics as it ages.
@@ -47,11 +48,13 @@ tier should be configured to use one or more replicas.
47
48
48
49
The content tier is required. System indices and other indices that aren't part
49
50
of a data stream are automatically allocated to the content tier.
51
+ // end::content-tier[]
50
52
51
53
[discrete]
52
54
[[hot-tier]]
53
55
=== Hot tier
54
56
57
+ // tag::hot-tier[]
55
58
The hot tier is the {es} entry point for time series data and holds your most-recent,
56
59
most-frequently-searched time series data.
57
60
Nodes in the hot tier need to be fast for both reads and writes,
@@ -60,22 +63,26 @@ For resiliency, indices in the hot tier should be configured to use one or more
60
63
61
64
The hot tier is required. New indices that are part of a <<data-streams,
62
65
data stream>> are automatically allocated to the hot tier.
66
+ // end::hot-tier[]
63
67
64
68
[discrete]
65
69
[[warm-tier]]
66
70
=== Warm tier
67
71
72
+ // tag::warm-tier[]
68
73
Time series data can move to the warm tier once it is being queried less frequently
69
74
than the recently-indexed data in the hot tier.
70
75
The warm tier typically holds data from recent weeks.
71
76
Updates are still allowed, but likely infrequent.
72
77
Nodes in the warm tier generally don't need to be as fast as those in the hot tier.
73
78
For resiliency, indices in the warm tier should be configured to use one or more replicas.
79
+ // end::warm-tier[]
74
80
75
81
[discrete]
76
82
[[cold-tier]]
77
83
=== Cold tier
78
84
85
+ // tag::cold-tier[]
79
86
When you no longer need to search time series data regularly, it can move from
80
87
the warm tier to the cold tier. While still searchable, this tier is typically
81
88
optimized for lower storage costs rather than search speed.
@@ -91,11 +98,13 @@ Fully mounted indices are read-only.
91
98
Alternatively, you can use the cold tier to store regular indices with replicas instead
92
99
of using {search-snaps}. This lets you store older data on less expensive hardware
93
100
but doesn't reduce required disk space compared to the warm tier.
101
+ // end::cold-tier[]
94
102
95
103
[discrete]
96
104
[[frozen-tier]]
97
105
=== Frozen tier
98
106
107
+ // tag::frozen-tier[]
99
108
Once data is no longer being queried, or being queried rarely, it may move from
100
109
the cold tier to the frozen tier where it stays for the rest of its life.
101
110
@@ -105,6 +114,7 @@ and load data from a snapshot repository. This reduces local storage and
105
114
operating costs while still letting you search frozen data. Because {es} must
106
115
sometimes fetch frozen data from the snapshot repository, searches on the frozen
107
116
tier are typically slower than on the cold tier.
117
+ // end::frozen-tier[]
108
118
109
119
[discrete]
110
120
[[configure-data-tiers-cloud]]
0 commit comments