[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-135?pag...
]
Sanne Grinovero commented on HSEARCH-135:
-----------------------------------------
Did you try to compare RAMDirectory performance to FSDirectory performance?
The filesystem is just slower the first time you have to read a segment/sector, after that
the operating system knows some very good tricks about I/O optimization given enough free
ram and you don't have to care (much) about memory requirements or have more work for
your garbage collector.
Also the OS is quite good at giving you transparently the correct version, so avoiding all
the mess with flushing and reloading.
My tests run on linux, but I think other oses should behave similarly.
You can still get "the best of both worlds" with indexreader "warmup",
having some query hit most segments in background before returning it to real searchers.
Of course, this is only possible if you can somehow prepare the indexreaders beforehand.
Create a RAMDirectoryProvider from an existing Lucene FSDirectory
-----------------------------------------------------------------
Key: HSEARCH-135
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-135
Project: Hibernate Search
Issue Type: New Feature
Components: directory provider
Reporter: Hardy Ferentschik
It would be nice to have the ability to use a Lucene RAM index which gets constucted from
an existing Lucene file based indexed. For example in an JMS setup the master could create
a file based Lucene index, share it out to the slaves which in turn use this file based
index to populate a RAM index. This would give you the best of two worlds.
Not sure how hard it would be to implement this in an unclustered environment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira