I looked through the documentation for an index, but didn't see this
mentioned though I easily could have missed it or not understood
something.
Is it possible to specify that an index should be durable (persisted
to disk), but always kept in memory? For my particular use case I have
a smaller index that will be heavily hit so pinning it in memory would
be preferred. I can see options for storing to disk, and in-memory
indexes, but not a combination of the two.
I looked through the documentation for an index, but didn't see this
mentioned though I easily could have missed it or not understood
something.
Is it possible to specify that an index should be durable (persisted
to disk), but always kept in memory? For my particular use case I have
a smaller index that will be heavily hit so pinning it in memory would
be preferred. I can see options for storing to disk, and in-memory
indexes, but not a combination of the two.
Hi Shay,
when using mmapfs, what happens to mapped addresses on ES restart?
does it lose all the in memory data, and the store actually changes to a regular file system storage?
or does it map all addresses once again?
If you restart ES, the JVM process exits and gives all memory back to
the OS, followed by another start of the JVM. There is nothing magic
about mmap in this context.
Jörg
Am 13.07.13 14:11, schrieb oreno:
Hi Shay,
when using mmapfs, what happens to mapped addresses on ES restart?
does it lose all the in memory data, and the store actually changes to a
regular file system storage?
or does it map all addresses once again?
Thanks Jörg,
I was looking for a solid in memory storage solution. I guess mmapfs is not
the one.
To be honest I don't really understand when it will be good practice to use
explicit 'in memory' storage.
It has no persistence or backup...
If you restart ES, the JVM process exits and gives all memory back to
the OS, followed by another start of the JVM. There is nothing magic
about mmap in this context.
Jörg
Am 13.07.13 14:11, schrieb oreno:
Hi Shay,
when using mmapfs, what happens to mapped addresses on ES restart?
does it lose all the in memory data, and the store actually changes to a
regular file system storage?
or does it map all addresses once again?
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [hidden email]http://user/SendEmail.jtp?type=node&node=4038073&i=0.
There is a "memory" (RAM only) store option, for keeping volatile data
in the JVM heap. This is useful in the case you only test ES (with
junit/testng, you don't create temp files) or for data from a persistent
source, where recreating by bulk indexing is faster/easier than gateway
storage (which is rarely the case). The "memory" option must not be
confused with search caches for filter/facets which are much more
important for performance.
If you mount a filesystem on a RAM disk and use mmapfs/niofs by pointing
the "path.data" config to it, you can pretty much achieve a better
effect than "memory" store, because OS might optimize I/O and Java might
avoid moving data over the JVM heap.
Jörg
Am 13.07.13 14:43, schrieb oreno:
Thanks Jörg,
I was looking for a solid in memory storage solution. I guess mmapfs
is not the one.
To be honest I don't really understand when it will be good practice
to use explicit 'in memory' storage.
It has no persistence or backup...
Thanks for the input.
1.I actually not looking for cache solution since my queries are pretty dynamic.
2.Won't mounting to RAM results in the lose of data once the ES restarts, same as in memory method?
3.Are you saying that mmapfs as no affect on search performance?
I only tried it because I read that it has in memory mapping along with file system storage
that I require for persistence.
4.What would you say is the best setting to have when you need the best search performance along with persistence for the indexed data?
There is a "memory" (RAM only) store option, for keeping volatile data
in the JVM heap. This is useful in the case you only test ES (with
junit/testng, you don't create temp files) or for data from a persistent
source, where recreating by bulk indexing is faster/easier than gateway
storage (which is rarely the case). The "memory" option must not be
confused with search caches for filter/facets which are much more
important for performance.
If you mount a filesystem on a RAM disk and use mmapfs/niofs by pointing
the "path.data" config to it, you can pretty much achieve a better
effect than "memory" store, because OS might optimize I/O and Java might
avoid moving data over the JVM heap.
Jörg
Am 13.07.13 14:43, schrieb oreno:
Thanks Jörg,
I was looking for a solid in memory storage solution. I guess mmapfs
is not the one.
To be honest I don't really understand when it will be good practice
to use explicit 'in memory' storage.
It has no persistence or backup...
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.