mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-14 17:05:36 +00:00
95f46f1212
We now have a very useful annotation to mark features or parameters as experimental. Let's use it! This commit replaces some custom text warnings with this annotation and adds this annotation to some existing features/parameters: - inner_hits (unreleased yet) - terminate_after (released in 1.4) - per-bucket doc count errors in the terms agg (released in 1.4) I also tagged with this annotation settings which should either be not needed (like the ability to evict entries from the filter cache based on time) or that are too deep into the way that Elasticsearch works like the Directory implementation or merge settings. Close #9563
96 lines
3.2 KiB
Plaintext
96 lines
3.2 KiB
Plaintext
[[index-modules-store]]
|
|
== Store
|
|
|
|
experimental[]
|
|
|
|
The store module allows you to control how index data is stored.
|
|
|
|
The index can either be stored in-memory (no persistence) or on-disk
|
|
(the default). In-memory indices provide better performance at the cost
|
|
of limiting the index size to the amount of available physical memory.
|
|
|
|
When using a local gateway (the default), file system storage with *no*
|
|
in memory storage is required to maintain index consistency. This is
|
|
required since the local gateway constructs its state from the local
|
|
index state of each node.
|
|
|
|
Another important aspect of memory based storage is the fact that
|
|
Elasticsearch supports storing the index in memory *outside of the JVM
|
|
heap space* using the "Memory" (see below) storage type. It translates
|
|
to the fact that there is no need for extra large JVM heaps (with their
|
|
own consequences) for storing the index in memory.
|
|
|
|
|
|
[float]
|
|
[[file-system]]
|
|
=== File system storage types
|
|
|
|
File system based storage is the default storage used. There are
|
|
different implementations or _storage types_. The best one for the
|
|
operating environment will be automatically chosen: `mmapfs` on
|
|
Windows 64bit, `simplefs` on Windows 32bit, and `default`
|
|
(hybrid `niofs` and `mmapfs`) for the rest.
|
|
|
|
This can be overridden for all indices by adding this to the
|
|
`config/elasticsearch.yml` file:
|
|
|
|
[source,yaml]
|
|
---------------------------------
|
|
index.store.type: niofs
|
|
---------------------------------
|
|
|
|
It can also be set on a per-index basis at index creation time:
|
|
|
|
[source,json]
|
|
---------------------------------
|
|
curl -XPUT localhost:9200/my_index -d '{
|
|
"settings": {
|
|
"index.store.type": "niofs"
|
|
}
|
|
}';
|
|
---------------------------------
|
|
|
|
The following sections lists all the different storage types supported.
|
|
|
|
[float]
|
|
[[simplefs]]
|
|
==== Simple FS
|
|
|
|
The `simplefs` type is a straightforward implementation of file system
|
|
storage (maps to Lucene `SimpleFsDirectory`) using a random access file.
|
|
This implementation has poor concurrent performance (multiple threads
|
|
will bottleneck). It is usually better to use the `niofs` when you need
|
|
index persistence.
|
|
|
|
[float]
|
|
[[niofs]]
|
|
==== NIO FS
|
|
|
|
The `niofs` type stores the shard index on the file system (maps to
|
|
Lucene `NIOFSDirectory`) using NIO. It allows multiple threads to read
|
|
from the same file concurrently. It is not recommended on Windows
|
|
because of a bug in the SUN Java implementation.
|
|
|
|
[[mmapfs]]
|
|
[float]
|
|
==== MMap FS
|
|
|
|
The `mmapfs` type stores the shard index on the file system (maps to
|
|
Lucene `MMapDirectory`) by mapping a file into memory (mmap). Memory
|
|
mapping uses up a portion of the virtual memory address space in your
|
|
process equal to the size of the file being mapped. Before using this
|
|
class, be sure your have plenty of virtual address space.
|
|
See <<vm-max-map-count>>
|
|
|
|
[[default_fs]]
|
|
[float]
|
|
==== Hybrid MMap / NIO FS
|
|
|
|
The `default` type stores the shard index on the file system depending on
|
|
the file type by mapping a file into memory (mmap) or using Java NIO. Currently
|
|
only the Lucene term dictionary and doc values files are memory mapped to reduce
|
|
the impact on the operating system. All other files are opened using Lucene `NIOFSDirectory`.
|
|
Address space settings (<<vm-max-map-count>>) might also apply if your term
|
|
dictionaries are large.
|
|
|