Matcher intro¶
LIM Matcher loads the most relevant indices from the storage and processes requests for matching.
Startup¶
At startup, matcher loads into memory all the latest version indices from index storage. The matcher configures Redis streams to accept messages for matching for all the labels of loaded indices.
Index reload¶
Since index storage may contain several versions of indices with a particular matching label, the matcher always tend to perform matching on the newer (i.e. more relevant) one.
Note
While reloading the index, the matcher does not accept requests for matching by corresponding label. However only one matcher can reload the index for a particular label at one time. Therefore it is recommended to run multiple matcher instances to be able to match across all the labels at any time.
Matching¶
LIM Matcher does not compare an inbound descriptor with all the listed descriptors, but moves along index (i.e graph) vertices. After moving to the first vertex, the service compares the incoming descriptor with all the vertices connected to the current vertex. When the most similar vertex is found, the comparison is performed with vertices connected to it. After several iterations, the descriptor with the highest similarity score is determined. The number of operations in this search is significantly lowered, which increases search performance a hundredfold.
LIM Matcher accepts matching requests via Redis streams, performs matching and sends matching result to the Redis channel specified in the request. In the background, LIM Matcher synchronizes Redis keys with labels acceptable for matching. It is recommended to use matching client to check whether the specific label index is loaded by matchers, and for matching requests. That is what the matching plugin does. When using the matching plugin, you can make HTTP requests to Luna Python Matcher Proxy as usual, and it will forward the acceptable requests to LIM Matcher.