CODEWITHSUNDEEP
indexingehcache
sxc731
sxc731

Reputation: 2638

searchable Ehcache indexing - what are the options?

Ehcache's 2.5.x documentation states that its standard implementation provides cache searching features without relying on indexing and manages to yield good performance (< 1s for caches of up to 1M elements). Experimentation verifies this claim. However, this does degrade (by O(N)) with larger caches.

The documentation further states that by using a distributed cache implementation ("Backed by the Terracotta Server Array"), one would gain the benefit of indexing. However there doesn't seem to be a solution for smaller caches of more than 1M elements of a sufficiently size small to not require distribution (ours would fit 1.2M elements in a ~1Gb cache).

Has anyone found a workaround/solution to provide indexing for such cases or does this entail the somewhat sledgehammer approach of distributing the cache?

It's also a little unclear as to whether this indexing feature would require a commercial Terracotta license (I was under the impression that portions of the Terracotta offering is available free of charge, albeit clearly without the support?)

Upvotes: 2

Views: 2108

Answers (1)

user1697575
user1697575

Reputation: 2848

I think EhCache indexing feature has nothing to do with Terracotta. Its a core feature of EhCache. I'm using both Ehcache and Ehcache backed by commercial version of Terracotta.

When you do provide ehcache.xml configuration you'll have to specify which fields are searcheable (this will trigger Lucene's indexing activity every time a new object is cached or updated/removed in cache)

Here a sample example of such configuration (I've setup maxBytesLocalHeap="1024m" as per your requirements):

<?xml version="1.0" encoding="UTF-8"?>
<ehcache maxBytesLocalHeap="1024m">
 <sizeOfPolicy maxDepth="2000" />
 <defaultCache eternal="false" timeToLiveSeconds="600"/>
 <cache name="myCacheablePOJO" eternal="true" statistics="true">
  <searchable>
   <searchAttribute name="field1" />
   <searchAttribute name="field2" />
   <searchAttribute name="field3" />
  </searchable>
 </cache>
</ehcache>

When you use Terracotta based implementatio of EhCache APIs you will have to have additional jars on the classpath and enable terracotta in the configuration:

<?xml version="1.0" encoding="UTF-8"?>
<ehcache maxBytesLocalHeap="1.3g">
 <sizeOfPolicy maxDepth="2000" />
 <defaultCache eternal="false" timeToLiveSeconds="600">
  <terracotta/>
 </defaultCache>
 <cache name="myCacheablePOJO" eternal="true" statistics="true">
  <searchable>
   <searchAttribute name="field1" />
   <searchAttribute name="field2" />
   <searchAttribute name="field3" />
   </searchable>
   <terracotta compressionEnabled="true" />
 </cache>
</ehcache>

Notice, that I've added "terracotta" tag to the cache name="myCacheablePOJO" with an optional attribute to enable object compression in cache (saves ram space with a fractional performance cost).

So, in other words you should be fine with 1.2M of elements in your local EhCache without Terracotta clustering. The only problem you should consider is fail-over. You should ask yourself the following questions:

  • What is my system caching strategy?
  • Can the system afford loosing cached data in case of JVM crash?
  • How data is populated in your local cache in case of JVM restart?

Upvotes: 1

Related Questions