OpenSearch/docs/reference/index-modules/store.asciidoc

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