Best Practices for Optimizing Searches

Construct searches by including only the data that is actually required.

Only use includeKeys( ) and/or includeAttribute( ) if those values are required for your application logic.

If you do not need values or attributes, be careful not to burden your queries with unnecessary work. For example, if result.getValue( ) is not called in the search results, do not use includeValues( ) in the query.

Consider if it would be sufficient to get attributes or keys on demand. For example, instead of running a search query with includeValues( ) and then result.getValue( ), run the query for keys and include cache.get( ) for each individual key.

Note:

The includeKeys( ) and includeValues( ) methods have lazy deserialization, meaning that keys and values are deserialized only when result.getKey( ) or result.getValue( ) is called. However, calls to includeKeys() and includeValues( ) do take time, so consider carefully when constructing your queries.

Searchable keys and values are automatically indexed by default. If you are not including them in your query, turn off automatic indexing with the following:

Limit the size of the result set. Depending on your use case, you might consider maxResults, an Aggregator, or pagination:

If getting a subset of all the possible results quickly is more important than receiving all the results, consider using query.maxResults(int number_of_results). Sometimes maxResults is useful where the result set is ordered such that the items you want most are included within the maxResults.

If all you want is a summary statistic, use a built-in Aggregator function, such as count(). For details, see the net.sf.ehcache.search.aggregator package in the Ehcache Javadoc.

Queries with iLike criteria and fuzzy (wildcard) searches might take longer than more specific queries.

If you are using a wildcard, try making it the trailing part of the string instead of the leading part ("321*" instead of "*123").

Tip:	If you want leading wildcard searches, you should create a <searchAttribute> with the string value reversed in it, so that your query can use the trailing wildcard instead.

When possible, use the query criteria “Between” instead of “LessThan” and “GreaterThan”, or “LessThanOrEqual” and “GreaterThanOrEqual”. For example, instead of using le(startDate) and ge(endDate), try not(between(startDate,endDate)).

Index dates as integers. This can save time and can also be faster if you have to do a conversion later on.