Open topic with navigation

Improve IDOL Performance > Improve Query Performance > Worked Example: Query for Numeric Values

# Worked Example: Query for Numeric Values

This topic discusses a number of different ways that you can query for numeric values , and the performance and configuration advantages and disadvantages of these configurations.

The following examples consider a query for a value in the `DocumentType` field. This field is generated by IDOL KeyView, and contains a numeric value. The following table describes the different types of query you can use to search for a value of 230 in the `DocumentType` field.

Query Name | Query Example | IDOL Configuration
--- | --- | ---
Unoptimized `EQUAL` | `action=Query&FieldText=EQUAL{230}:DocumentType` | None
Optimized `EQUAL` | `action=Query&FieldText=EQUAL{230}:DocumentType` | `DocumentType` field set as `NumericType`.
Unoptimized `MATCH`{} | `action=Query&FieldText=MATCH{230}:DocumentType` | None
Optimized `MATCH`{} | `action=Query&FieldText=MATCH{230}:DocumentType` | `DocumentType` field set as `MatchType`.
Numeric `Text` Query | `action=Query&Text=230:DocumentType` | `DocumentType` field set as `Index` field type.
`FieldCheck` | `action=Query&Text=*&FieldCheck=230` | `DocumentType` field set as `FieldCheckType`.

## Unoptimized EQUAL

In an unoptimized `EQUAL` query, you use the `FieldText` `EQUAL` operator on a field that has no special configuration. This option might make sense when you very rarely query against the field, and when saving RAM and disk space is more important than query performance.

`EQUAL` queries work only against numeric values (such as `12554`, `43.27`, `-3712.39`). Do not use these queries for arbitrary strings (such as `dog`, `cat`, `apples`). Additionally, `EQUAL` matches all numeric variations of a value, so that `1` is the same as `01`, `001`, and `1.0`.

## Optimized EQUAL

In optimized `EQUAL` queries, you use the `FieldText` `EQUAL` operator on a field that you have configured with the `NumericType` property. `NumericType` fields have the additional advantage that they are optimized for the `RANGE`, `GREATER`, and `LESS` operators, which allow you to search for a range of numeric values.

Optimized `EQUAL` queries are much faster than the unoptimized equivalent for exact-value matches, at the cost of RAM and disk space. Memory usage is proportional to the number of `NumericType` fields, and the number of instances of those fields. You can limit the memory usage for a field by using the `NumericNormalMaxMem` configuration parameter. Disk usage is the same as the memory usage.

`EQUAL` queries work only against numeric values (such as `12554`, `43.27`, `-3712.39`). Do not use these queries for arbitrary strings (such as `dog`, `cat`, `apples`). Additionally, `EQUAL` matches all numeric variations of a value, so that `1` is the same as `01`, `001`, and `1.0`.

## Unoptimized MATCH

In an unoptimized `MATCH` query, you use the `FieldText` `MATCH` operator on a field that has no special configuration. In general, HPE does not recommend using `MATCH` for numeric value matching, because the `EQUAL` operator generally uses less memory than `MATCH` for the same exact value match. However, you might need to use `MATCH` in the case where you need to match numeric values as strings, for example when you treat `001` as different to `1`. In this case, an unoptimized `MATCH` query might be appropriate when you very rarely query against the field, and when saving RAM and disk space is more important than query performance.

## Optimized MATCH

In optimized `MATCH` queries, you use the `FieldText` `MATCH` operator on a field that you have configured with the `MatchType` property. In general, HPE does not recommend using `MATCH` for numeric value matching, because the `EQUAL` operator generally uses less memory than `MATCH` for the same exact value match. However, you might need to use `MATCH` in the case where you need to match numeric values as strings, for example when you treat `001` as different to `1`. In this case, an optimized `MATCH` query are much faster than the unoptimized equivalent for exact-value matches, at the cost of RAM and disk space. In particular:

- Memory usage is proportional to the number of fields and the number of unique values in each field. In the same way as for `NumericType` fields, you can limit the memory for a field by using the `NumericNormalMaxMem` configuration parameter.

- Disk usage is proportional to the number of fields and the number of unique values.

## Numeric Text Query

In a numeric text query, you use the Text parameter with a field restriction, for example `Text=230:DocumentType`. For this query, the field must be an `Index` type field. There is no equivalent to optimized or unoptimized for this type of query.

Note: For numeric queries of this type on an `Index` field, you must have `IndexNumbers` set to `1`. If you do not want to use this setting in general, you can use the `IndexNumbersType` field property for individual fields to use a more restrictive value (for example, you might set `IndexNumbers` to `1` for your system, and then configure some fields to have `IndexNumber` set to `2` to index only non-numeric and alphanumeric terms).

When using this type of query, bear in mind that if the numeric values occur in other `Index` fields, it might affect the term weight and query relevance . You must also take care with character settings such as `TangibleCharacters` when negative and decimal values are possible.

For this type of query, consider the following notes on performance and system usage:

- There is no appreciable memory usage for index terms.

- Disk usage is proportional to the total number of terms, and the number of occurrences.

- Indexing numeric terms often expands the number of unique terms in the index overall, which affects both query and index performance. Querying for a large number of terms (independent of their individual occurrences) generally has the most negative effect on performance.

## FieldCheck

In some cases where you only need to use one field name, you can use `FieldCheck` in a similar way to `EQUAL` or `MATCH`. You can only query for one value at a time, which means that you cannot use Boolean expressions to find multiple values. Also, you can only configure one field as `FieldCheck` in a server, so that if you have multiple applications operating on the same index, they must use the same `FieldCheck` field. Memory and disk usage are not affected by the `FieldCheck` field.

Related Topics

- IDOL Internal Storage and Indexes

- Memory Usage in IDOL Server

- Reduce Memory Usage

- Numeric and Alphanumeric Terms

© 2016 Hewlett Packard Enterprise Development LP | Send documentation feedback to HPE Close We welcome your comments! To open the configured email client on this computer, open an email window. Otherwise, copy the information below to a web mail client, and send this email to AutonomyTPFeedback@hpe.com. Product: Topic Title: Help Topic: Feedback:

_HP_HTML5_bannerTitle.htm