@@ -38,10 +38,9 @@ much data to searches for a given cluster size.
38
38
39
39
=== Using searchable snapshots
40
40
41
- A searchable snapshot can be searched just like any other index.
42
- {search-snaps-cap} are often used to access a large archive of historical data,
43
- for which searches may sometimes be complex and time-consuming.
44
- <<async-search>> is particularly useful for these long-running searches.
41
+ A searchable snapshot can be searched just like any other index. Since there is
42
+ a copy of the searchable snapshot on the nodes in the cluster its searches will
43
+ perform similarly to searches on a regular index.
45
44
46
45
The shards of searchable snapshots are also allocated just like shards of any
47
46
other index. You can, for instance, use <<shard-allocation-filtering>> to
@@ -78,6 +77,16 @@ will be a brief window of time before {es} allocates these shards elsewhere.
78
77
During this window of time the cluster health will be `red` and searches that
79
78
hit these shards will fail or return partial results.
80
79
80
+ [TIP]
81
+ ====
82
+ {search-snaps-cap} are ideal for managing a large archive of historical data.
83
+ Historical information is typically searched less frequently than recent data
84
+ and therefore may not need replicas for their performance benefits.
85
+
86
+ You can use <<async-search>> with {search-snaps-cap}, which is especially
87
+ useful for more complex or time-consuming searches.
88
+ ====
89
+
81
90
=== How searchable snapshots work
82
91
83
92
When you mount a searchable snapshot index, {es} allocates its shards onto the
0 commit comments