Performance impact of RRN

You can use EQL expressions for Record Relationship Navigation (RRN).

Important: You must configure the MDEX Engine in order to enable Record Relationship Navigation. This capability is an optional module that extends the MDEX Engine. Endeca customers who are entitled by their license to use Record Relationship Navigation can find instructions on the Endeca Support site. Contact your Endeca representative if you need to obtain a Record Relationship Navigation license.

Use the following recommendations to speed up the RRN queries:

When writing RRN filters, take into account that RRN filter expressions work from the inside out. That is, the innermost, or most nested, expressions are evaluated by the MDEX Engine before the outer ones. The following example illustrates this bottom-up processing:
```
collection()/record 
  [ 
    author_bookref = collection()/record 
    [ 
      book_year = "1843" 
    ] 
    /book_id 
  ] 
```
The MDEX Engine first finds the records that have the book_year property set to “1843”. Then it finds the list of all of the values in the book_id property for that set of records. Finally, it finds the set of records with the author_bookref property set to any of the values in that list.
To speed up RRN queries, assign different property names for records representing different concepts. This is because RRN query performance depends on the number of records in the “nested” EQL query. Keep the number of records that match results for the innermost expression of the RRN filter relatively small. For example, in this query:
```
collection()/record[
	record_type = "Film"
	and
	endeca:matches(., "title", "Godfather") 
	and 
	actor_id = collection()/record[
			record_type = "Actor" 
			and
			gender = "male"
			and
			nationality = "Italian"
]
```
the MDEX Engine uses its bottom-up query execution strategy in the following way:

It first evaluates the inner query and finds the set of records for which the record_type property has the value "Actor," the gender property has the value "male," and the nationality property has the value "Italian."

It then creates a collection of all the values of the id property for this set of records.

Next, it iterates over the set of “/id” values to filter the set of "Film" records. Thus, if the size of the collection of “/id” values is really large, the iteration can be relatively slow.

In this example, if the number of film IDs that are returned from the innermost filter to the Actor filter is relatively small, the RRN filter that will evaluate these records will be fast; if the number of IDs returned is large, the RRN evaluation will be slow.

To generalize, when you know that the number of records that will have to be evaluated for a RRN filter is quite large (in this example, it is the number of Italian male actors), a query could be slow. To solve this problem, one solution is to use the user interface and force the users to narrow down the set of records early on in the navigation process.
If this is not a reasonable solution for your application, and you cannot guarantee that the user’s navigation path will necessarily limit the set of records, you can narrow down this set by limiting the number of records that match in the innermost query, as shown in this example:
```
collection()/record[
	record_type = "Film"
	and
	endeca:matches(., "title", "Godfather") 
	and 
	actor_id = collection()/record[
			record_type = "Actor" 
			and
			gender = "male"
			and
			nationality = "Italian"
			and
			film_id = collection()/record[
					record_type = "Film"
					and
					endeca:matches(., "title", "Godfather")
				]/id
		]/id
]
```
This method is mimicking a top-down execution of a query.

While building an application, test the performance of this inner query with EQL statistics logging to evaluate the time spent in it.
To speed up RRN queries, assign different property names for different record types of the RRN collection()/record function.
For example, consider this generic RRN query:
```
collection()/record[propertyKey1 = recordPath/propertyKey2]
```
where:

propertyKey1 is the NCName of an Endeca property on a record type to be filtered, such as record of type Vineyard. The resulting records will have this property.

recordPath is one or more of the collection()/record functions.

propertyKey2 is the NCName of an Endeca property on another record type, such as record of type Wine, that will be compared to propertyKey1. Records that satisfy the comparison will be added by the MDEX Engine to the returned set of records.

In this example, instead of assigning the same value of “ID” for propertyKey1 and propertyKey2, assign two different property names— “wine_reference_ID” on a record representing a vineyard, and “wine_ID” on a record representing a wine. As the number of records evaluated for the RRN query increases, having the naming convention with different property names for different record types has a greater effect on performance.

When properties with the same name are assigned on each side of the RRN query, this negatively affects RRN query performance.

For more information about RRN, see the Endeca Advanced Development Guide.