store.asciidoc 4.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130
  1. [[index-modules-store]]
  2. == Store
  3. The store module allows you to control how index data is stored.
  4. The index can either be stored in-memory (no persistence) or on-disk
  5. (the default). In-memory indices provide better performance at the cost
  6. of limiting the index size to the amount of available physical memory.
  7. When using a local gateway (the default), file system storage with *no*
  8. in memory storage is required to maintain index consistency. This is
  9. required since the local gateway constructs its state from the local
  10. index state of each node.
  11. Another important aspect of memory based storage is the fact that
  12. Elasticsearch supports storing the index in memory *outside of the JVM
  13. heap space* using the "Memory" (see below) storage type. It translates
  14. to the fact that there is no need for extra large JVM heaps (with their
  15. own consequences) for storing the index in memory.
  16. [float]
  17. [[store-throttling]]
  18. === Store Level Throttling
  19. The way Lucene, the IR library elasticsearch uses under the covers,
  20. works is by creating immutable segments (up to deletes) and constantly
  21. merging them (the merge policy settings allow to control how those
  22. merges happen). The merge process happens in an asynchronous manner
  23. without affecting the indexing / search speed. The problem though,
  24. especially on systems with low IO, is that the merge process can be
  25. expensive and affect search / index operation simply by the fact that
  26. the box is now taxed with more IO happening.
  27. The store module allows to have throttling configured for merges (or
  28. all) either on the node level, or on the index level. The node level
  29. throttling will make sure that out of all the shards allocated on that
  30. node, the merge process won't pass the specific setting bytes per
  31. second. It can be set by setting `indices.store.throttle.type` to
  32. `merge`, and setting `indices.store.throttle.max_bytes_per_sec` to
  33. something like `5mb`. The node level settings can be changed dynamically
  34. using the cluster update settings API. The default is set
  35. to `20mb` with type `merge`.
  36. If specific index level configuration is needed, regardless of the node
  37. level settings, it can be set as well using the
  38. `index.store.throttle.type`, and
  39. `index.store.throttle.max_bytes_per_sec`. The default value for the type
  40. is `node`, meaning it will throttle based on the node level settings and
  41. participate in the global throttling happening. Both settings can be set
  42. using the index update settings API dynamically.
  43. [float]
  44. [[file-system]]
  45. === File system storage types
  46. File system based storage is the default storage used. There are
  47. different implementations or _storage types_. The best one for the
  48. operating environment will be automatically chosen: `mmapfs` on
  49. Windows 64bit, `simplefs` on Windows 32bit, and `default`
  50. (hybrid `niofs` and `mmapfs`) for the rest.
  51. This can be overridden for all indices by adding this to the
  52. `config/elasticsearch.yml` file:
  53. [source,yaml]
  54. ---------------------------------
  55. index.store.type: niofs
  56. ---------------------------------
  57. It can also be set on a per-index basis at index creation time:
  58. [source,json]
  59. ---------------------------------
  60. curl -XPUT localhost:9200/my_index -d '{
  61. "settings": {
  62. "index.store.type": "niofs"
  63. }
  64. }';
  65. ---------------------------------
  66. The following sections lists all the different storage types supported.
  67. [float]
  68. [[simplefs]]
  69. ==== Simple FS
  70. The `simplefs` type is a straightforward implementation of file system
  71. storage (maps to Lucene `SimpleFsDirectory`) using a random access file.
  72. This implementation has poor concurrent performance (multiple threads
  73. will bottleneck). It is usually better to use the `niofs` when you need
  74. index persistence.
  75. [float]
  76. [[niofs]]
  77. ==== NIO FS
  78. The `niofs` type stores the shard index on the file system (maps to
  79. Lucene `NIOFSDirectory`) using NIO. It allows multiple threads to read
  80. from the same file concurrently. It is not recommended on Windows
  81. because of a bug in the SUN Java implementation.
  82. [[mmapfs]]
  83. [float]
  84. ==== MMap FS
  85. The `mmapfs` type stores the shard index on the file system (maps to
  86. Lucene `MMapDirectory`) by mapping a file into memory (mmap). Memory
  87. mapping uses up a portion of the virtual memory address space in your
  88. process equal to the size of the file being mapped. Before using this
  89. class, be sure your have plenty of virtual address space.
  90. See <<vm-max-map-count>>
  91. [[default_fs]]
  92. [float]
  93. ==== Hybrid MMap / NIO FS added[1.3.0]
  94. The `default` type stores the shard index on the file system depending on
  95. the file type by mapping a file into memory (mmap) or using Java NIO. Currently
  96. only the Lucene term dictionary and doc values files are memory mapped to reduce
  97. the impact on the operating system. All other files are opened using Lucene `NIOFSDirectory`.
  98. Address space settings (<<vm-max-map-count>>) might also apply if your term
  99. dictionaries are large.
  100. [float]
  101. [[store-memory]]
  102. === Memory
  103. The `memory` type stores the index in main memory, using Lucene's
  104. `RamIndexStore`.