IMPORTANT: No additional bug fixes or documentation updates
will be released for this version. For the latest information, see the
current release documentation.
Store
editStore
editThe store module allows you to control how index data is stored and accessed on disk.
File system storage types
editThere are different file system implementations or storage types. By default, Elasticsearch will pick the best implementation based on the operating environment.
This can be overridden for all indices by adding this to the
config/elasticsearch.yml
file:
index.store.type: niofs
It is a static setting that can be set on a per-index basis at index creation time:
PUT /my_index { "settings": { "index.store.type": "niofs" } }
This is an expert-only setting and may be removed in the future.
The following sections lists all the different storage types supported.
-
fs
-
Default file system implementation. This will pick the best implementation
depending on the operating environment, which is currently
mmapfs
on all supported systems but is subject to change. -
simplefs
-
The Simple FS 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 theniofs
when you need index persistence. -
niofs
-
The NIO FS 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
-
The MMap FS 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 you have allowed plenty of virtual address space.