Search Process

Livelink Search Process

Search Federator:

Otsearchfederator is the process involved for this task. Search federator is responsible for:

• Accepting search query from content server and sending it to search engines
• Collecting and sorting result received from search engines
• Removing duplicate entries in search result

Search Engine:

Search Engine performs the task of searching queries in search index. The process involved is “otsearchengine”. Each search engine carries out the search in its partition. They are also involved in building facets, computing position information for highlighting search results.

OT does not reveal the algorithm followed by search engine to carry out its activity.

Search Index:

• Consists of several partitions, each having an index engine and one or more search engine
• Object’s Content data is stored in disk while it’s metadata is stored in RAM (for faster retrieval)
• Physically, index is stored in OTHOME\index\enterprise\index1 (index1 for first partition) and IPool is stored in OTHOME\index\enterprise\data_flow
• VerifyIndex tool can be used to check if the index is corrupt [enterprise data source-> maintenance -> verify contents of the index]
• Partitions can be Read/Write, Update-Only, Read-Only. Changing partition’s mode from Read/Write to Read only or Update only, also moves the metadata from memory to disk.

 Partitions- Search index can be divided horizontally into several pieces called “partitions”.

SE10 can often provide better indexing or searching performance by allowing operations to be distributed to multiple partitions. These partitions can be run on separate physical or virtual computers or CPUs to improve performance.

Partition Implementation Overview

Every partition is a self-contained subset of the search index. Every one of them has its own index files, a Search Engine, and an Index Engine. The partitions are tied together by the Update Distributor (for indexing) and by the Search Federator (for queries).

Each partition is relatively independent of the other partitions in the system during indexing. If one partition is given an object to index, the other partitions are idle. The Update Distributor can distribute the indexing load across multiple partitions. For systems with high indexing volumes, using multiple partitions this way can help achieve higher performance, since partitions can be indexing objects in parallel.

A search query normally is serviced by all partitions. Only partitions containing matches to the query will return results. The Search Federator will blend results from multiple partitions into a consolidated set of search results.

• Update-Only Partitions - In this mode, the partition will not accept new objects to index, but it will update existing objects or delete existing objects. If a partition is marked as Update-Only, then the Update Distributor will not send it new objects.
• Read-Only Partitions - In this mode, the partition will respond to search queries, but will not process any indexing requests. Objects in the partition cannot be added removed or modified.
• Read-Write Partitions - For completeness, the normal mode of operation for a partition is “Read-Write” mode. In this mode, the partition will accept new objects, can delete objects and update objects.

Index server:

The main process for index server is otdb. Child processes of otdb are:

1.    Otupbld-index building process, adding, updating and deleting

2.    Otmrg-merging smaller and many indexes into one large index

3.    Otcomp- compacting index when 30% of it gets deleted

4.    Mltcon- multiple connection manager

Otsumlog utility can be used to generate separate log files for each child process of index server (otdb)