Overview

To improve performance, the space can maintain an index for entry field values. This speeds read and take operations, but consumes resources, so only fields used for matching should be indexed. GigaSpaces support hash based index used for equality matching (used by default) and B-tree index used for bigger/less than matching (need the Extended Indexing to be turned on). You can automatically index the first n fields of each class (implicit indexing) or index certain fields of a specific class (explicit indexing).

There are three types of indexing:

• Implicit Indexing – when enabled, the implicit indexing automatically indexes all the class attributes that are not indexed programmatically. Implicit Indexing is managed through the <number-implicit-indexes> tag in the space schema configuration file.
• Explicit Indexing – allows you to specify programmatically which fields of an Entry class are indexed.
• Extended indexing – when enabled, a btree index is maintained for all space indexed class attributes.

Implicit Indexing

If the Implicit Indexing is enabled, GigaSpaces will automatically index all the class attributes that are not indexed programmatically. Implicit Indexing is managed through the <number-implicit-indexes> tag in the space schema configuration file.

GigaSpaces recommends disabling the Implicit Indexing since it might index Entries without real need. When the Implicit Indexing is turned on, the first String, Integer or Long class attributes field values are indexed. For example, the following class:

public class myClass implements Entry
{
  public String a;
  public Long b;
  public Integer c;
  public String d;
}

• When having the <number-implicit-indexes>0</number-implicit-indexes> as part of the space schema using a transient space the first 2 fields will be indexed - i.e. attribute a and attribute b values.
• When having the <number-implicit-indexes>0</number-implicit-indexes> as part of the space schema using a persistent space the first field will be indexed - i.e. attribute a values.
• When having the <number-implicit-indexes>3</number-implicit-indexes> as part of the space schema using a persistent or transient space the first 3 fields will be indexed - i.e. attribute a , b and c values.

Setting the <number-implicit-indexes>-1</number-implicit-indexes> will not implicitly indexed any of the entry classes field values for all space Entries unless explicit indexing has been used.

Explicit Indexing

This section is relevant for the JavaSpaces API only. JDBC API allows you to index attribute using the standard JDBC API.

You can specify programmatically which fields of an Entry class are indexed. You must explicitly request indexing on each Entry class even if it extends another indexed class. If you want the space to create an index for specific fields of an Entry class, implement the public static String[] __getSpaceIndexedFields() method that specifies the names of the fields that are to be indexed.

For example, lets take the following Person class:

public class Person implements Entry
{
  public String m_Id;
  public String m_Name;
  public Integer m_YearOfBirth;
  public String m_Email;

  public static String[] __getSpaceIndexedFields()
  {
    String[] indexedFields = { "m_Id", "m_Name", "m_Email" };
    return indexedFields;
  }
}

It has four fields, of which only three are indexed, as determined by the __getSpaceIndexedFields() method. Note that __getSpaceIndexedFields() must be a public static method.

Having the __getSpaceIndexedFields() defined as part of the class overrides the number-implicit-indexes value for the relevant class done at the space level.

Partitioned Space Uses the First Indexed Field Value Hashcode for Entry Classes When running a partitioned space (using the hash-based load-balancing policy), operations are routed to the relevant partition based on the Entry's first indexed field value hashcode. The first indexed field value hashcode is determined with Entry-based classes by sorting the indexed field according to their names in an ascending order, and using the first indexed field value hashcode to rout the operation to the correct partition. POJO-based Entries use the @SpaceRouting annotation to determine which partition the operation is routed to (supported in GigaSpaces 5.2 and onwards). ExternalEntry-based Entries use the routingFieldName to determine which partition the operation is routed to (supported in GigaSpaces 5.2 and onwards). PONO-based Entries use the RoutingIndex attribute to determine which partition the operation is routed to (supported in GigaSpaces 5.2 and onwards). For more details on the hash-based load-balancing policy, refer to the Load-Balancing Group - Cluster Schema section.

Extended Indexing

To turn on the btree index, modify the space schema configuration file as follows (note the asterisk):

<extended-match>
   <enabled-classes>*</enabled-classes>
   <regular-expressions-cache-size>300</regular-expressions-cache-size>
</extended-match>

By default the btree index is not maintained for indexed class attributes. Leaving the btree index turned on impacts the write performance since there would be 2 index list maintained – the hash index and the btree index.

The <enabled-classes>*</enabled-classes> can be replaced with a list of class names separated with commas that you want to index using the btree index.
For example:

<enabled-classes>classA,classB</enabled-classes>

Indexing Options Summary

<space-config>
   <number-implicit-indexes>-1</number-implicit-indexes>
   <engine>
      <extended-match>
         <enabled-classes></enabled-classes>
         <regular-expressions-cache-size>300</regular-expressions-cache-size>
      </extended-match>
   </engine>
</space-config>