Skip to content

Commit 8beb64b

Browse files
committed
More performance idea to a TIP
1 parent 29402a5 commit 8beb64b

File tree

1 file changed

+13
-4
lines changed

1 file changed

+13
-4
lines changed

docs/reference/searchable-snapshots/index.asciidoc

Lines changed: 13 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -38,10 +38,9 @@ much data to searches for a given cluster size.
3838

3939
=== Using searchable snapshots
4040

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.
4544

4645
The shards of searchable snapshots are also allocated just like shards of any
4746
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.
7877
During this window of time the cluster health will be `red` and searches that
7978
hit these shards will fail or return partial results.
8079

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+
8190
=== How searchable snapshots work
8291

8392
When you mount a searchable snapshot index, {es} allocates its shards onto the

0 commit comments

Comments
 (0)