MegaMatcher and MegaMatcher Accelerator in High Productivity Systems

Different large-scale biometric projects may require specific system performance. These matching engines and architectures may be used depending on the required matching speed, database size and system availability:

• Single Matching Server;
• Cluster of PCs running MegaMatcher components;
• Single MegaMatcher Accelerator 4.0 Standard or Extended unit;
• Cluster of MegaMatcher Accelerator 4.0 Standard or Extended units.

The charts below compare the different architectures for high performance AFIS or multi-biometric systems.

Matches 136,000 fingerprints or 860,000 faces or 920,000 irises per second. Requires MegaMatcher 4.3 Standard SDK.	Matches up to several million fingerprints or faces or irises per second. Requires MegaMatcher 4.3 Extended SDK.
Matches 35,000,000 fingerprints or 70,000,000 irises per second. Requires MegaMatcher 4.3 SDK, VeriFinger 6.5 SDK or VeriEye 2.5 SDK for client application development and 1 MegaMatcher Accelerator 4.0 Standard software installation.	Matches from 70,000,000 to 350,000,000 fingerprints or from 140,000,000 to 700,000,000 irises per second. Requires MegaMatcher 4.3 SDK, VeriFinger 6.5 SDK or VeriEye 2.5 SDK for client application development and multiple MegaMatcher Accelerator 4.0 Standard software installations for reaching the required performance.
Matches 100,000,000 fingerprints or 200,000,000 irises per second. Requires MegaMatcher 4.3 SDK, VeriFinger 6.5 SDK or VeriEye 2.5 SDK for client application development and 1 MegaMatcher Accelerator 4.0 Extended unit.	Matches from 200,000,000 to several billions fingerprints or from 400,000,000 to several billions irises per second. Requires MegaMatcher 4.3 SDK, VeriFinger 6.5 SDK or VeriEye 2.5 SDK for client application development and multiple MegaMatcher Accelerator 4.0 Extended units for reaching the required performance.

It is possible to use more than one architecture within a large-scale biometric system to reach optimal system performance and/or availability. For example, MegaMatcher Accelerator 4.0 unit(s) can be used for candidates selection using irises or several fingerprints, and then the results can be validated on Matching Server or Cluster with other biometric modalities. Also, two or more Clusters Servers or MegaMatcher Accelerator 4.0 clusters can be connected together for high availability system.

Single Matching Server

The architecture with a single Matching Server is intended to be used in moderate size systems like local AFIS or multi-biometric system which do not have strict requirements on performance or availability. The Matching Server software is available in MegaMatcher 4.3 Standard and Extended SDKs, as well as in VeriFinger 6.5 Extended SDK, VeriLook 5.2 Extended SDK, VeriSpeak 1.1 Extended SDK and VeriEye 2.5 Extended SDK.

A PC running Matching Server software accepts identification requests from client-side components for fingerprint, face, voice and/or iris biometrics and returns back the identification results. Up to 136,000 fingerprints or 860,000 faces or 920,000 irises per second can be matched on single Matching Server (on Intel Core 2 Q9400 processor running at 2.67 GHz).

The Matching Server can be also used for multi-biometric systems that use any combination of these biometric modalities: fingerprints, faces, voiceprints and/or irises. See technical specifications for more information on fingerprint, face, voice, iris and fused matching engines performance.

Cluster of PCs running MegaMatcher components

This architecture is designed for high productivity AFIS or multi-biometric system with millions of biometric templates stored in the database. The Cluster Server component is available in MegaMatcher Extended SDK.

Cluster Server distributes identification task over computers connected to the network. A biometric system based on Cluster Server software can be scaled up anytime to meet changing project requirements in increasing user amount or request environment. The cluster software consists of a Cluster Server and software for cluster nodes that run fingerprint, face, voice and/or iris components.

The Cluster Server accepts requests from client side, manages cluster work, distributes tasks over cluster nodes, collects results, reports them back to client side. Also it communicates with the main database which stores the biometric data.

Each cluster node matches up to 136,000 fingerprints or 860,000 faces or 920,000 irises per second (on Intel Core 2 Q9400 processor running at 2.67 GHz). The Cluster Server can be also used for multi-biometric systems that use any combination of these biometric modalities: fingerprints, faces, voiceprints and/or irises. See technical specifications for more information on fingerprint, face, voice, iris and fused matching engines performance.

A cluster node contains part of the main database, performs identification tasks in it and reports results to the Cluster Server. The node must have enough memory to store that database part, as all data is kept in memory during identification to achieve the best matching speed. A larger number of nodes results in faster matching, because each node operates on a smaller part of the database.

The cluster node uses database to store its database part and in order to perform relational queries, such as filter persons by gender, age, living place.

The amount of required cluster nodes is calculated is this way:

1. The whole database should fit into nodes memory (RAM). For example, if there are 10GB of biometric data and each node has 2GB of free memory available, at least 5 nodes should be used as otherwise the database will not fit into nodes memory and the cluster will not work.
2. The identification speed should satisfy project requirements. The speed requirements may be defined indirectly via identification request response time and/or peak hour request quantity with a given database.
   • Response time. For example, a database stores biometric data for 1 million people with 2 fingerprints for each of them, and the response time for an identification request should be 1 second. At least 15 cluster nodes should be used to provide the required response time.
   • Peak hour request quantity. For example, the project with the same database as above requires to process 5,000 identification requests at the peak hour. At least 21 cluster nodes should be used to provide the required peak hour availability.

These methods of fault tolerance are implemented in Cluster Server software:

1. Spare nodes (enabled by default). A spare node "waits" until an operating node fails and is used to replace the failed one by copying the part of database that was used in the failed node. If the failed node restored, it become the spare node.
2. Re-split tasks and database over existing nodes. If a node fails, the system finishes all tasks which are not related with the failed node, reinitializes nodes again by re-splitting the database over them and continues tasks passed into cluster. As a result the overall cluster performance decreases but the cluster continues to operate until the failed node is fixed or replaced.
   Note, that the database re-split is possible only if total amount of memory available in the remaining nodes is larger than the database size.
3. Spare Cluster Servers. A secondary Cluster Server may run within a cluster synchronized with the primary Cluster Server. If the primary Cluster Server becomes not available (due to crash or network problems), the secondary one replaces it on-the-fly and continues the cluster operation as new primary server. If the failed Cluster Server becomes available some time later, it can synchronize with the operating one and start acting as the new secondary server.
   There may be more than one spare Cluster Server within the cluster; the spare Cluster Servers will be organized in line, automatically maintain the line and replace the failed primary server in turn.
4. Parallel Cluster Servers. A parallel "spare" cluster may be run together with the main cluster and keep the data synchronized between the clusters. If the primary Cluster Server becomes not available, the parallel cluster replaces on-the-fly the failed one and keeps serving identification requests.

We recommend to leave at least 10%-20% free memory reserve when calculating the amount of used nodes in a cluster for both fault tolerance methods. The memory reserve would allow to avoid situations when the system can not continue work as it has not enough resourses.

Single MegaMatcher Accelerator 4.0 Standard or Extended unit

MegaMatcher Accelerator 4.0 is a solution for large-scale AFIS and multi-biometric projects and is available in two versions:

• MegaMatcher Accelerator 4.0 Standard is intended for biometric identification projects with up to several million people enrolled in database. This version includes ready-to-use server-side fingerprint and/or iris matching software for installation on a PC with Intel Core i7 processor and 12 GB of RAM. A single MegaMatcher Accelerator 4.0 Standard unit can store 4,000,000 fingerprints or 5,000,000 irises and matches 35,000,000 fingerprints or 70,000,000 irises per second. See technical specifications for more information on performance.
• MegaMatcher Accelerator 4.0 Extended is a solution for national-scale biometric identification projects with millions of people enrolled in database. This version includes ready-to-use HP Proliant server hardware with pre-installed OS and fingerprint and/or iris matching software. A single MegaMatcher Accelerator 4.0 Extended unit can store 40,000,000 fingerprints or 50,000,000 irises and matches 100,000,000 fingerprints or 200,000,000 irises per second. See technical specifications for more information on performance.

A MegaMatcher Accelerator 4.0 unit accepts identification requests from PCs that run client-side software based on components for fingerprint, iris or face biometrics, performs identification and returns back the results.

MegaMatcher Accelerator can be also used as a part of scalable multi-biometric identification system that uses fingerprint, face and/or iris modalities. The fingerprints and/or irises would be matched using MegaMatcher Accelerator(s), whereas other modalities would be matched using Matching Server or Cluster Server software depending on project size and performance requirements. Also MegaMatcher Accelerator 4.0 software includes fingerprint, face and iris matching engines that may be used for results validation after fast fingerprint or iris matching inside the Accelerator unit instead of using MegaMatcher Server or Cluster.

Cluster of MegaMatcher Accelerator 4.0 Standard or Extended units

MegaMatcher Accelerator 4.0 Standard and Extended versions already include cluster software, thus multiple MegaMatcher Accelerator 4.0 Standard or Extended units can be connected via network to a cluster.

To create a cluster, one MegaMatcher Accelerator unit is assigned as a primary unit in the cluster while other MegaMatcher Accelerator units act as cluster nodes. Note that the primary unit of MegaMatcher Accelerator cluster will still perform fast fingerprint and/or iris matching while using only a small part of its resources for managing the cluster.

Each MegaMatcher Accelerator 4.0 Standard unit in the cluster matches 35 million fingerprints or 70 million irises per second, and each MegaMatcher Accelerator 4.0 Extended unit matches 100 million fingerprints or 200 million irises per second.

When started, the primary unit splits the whole biometric database, which is stored on its hard disk, and send parts of the database to all MegaMatcher Accelerators in the cluster. Later the primary unit waits for fingerprint and/or iris identification requests from client side, then distributes the identification request to the units of the cluster and returns the identification results to the client side.

The cluster of MegaMatcher Accelerators can be scaled up anytime to meet changing project requirements in increasing user amount or request environment. A larger number of MegaMatcher Accelerator units results in faster matching and higher number of requests processed, because each unit operates on a smaller part of the database.

For example, there is a database with 15 million people biometric data (4 fingerprints for each user, 60 million fingerprints in total). The amount of required MegaMatcher Accelerator units is calculated is this way:

1. The whole database should fit into memory of the MegaMatcher Accelerator units. A single MegaMatcher Accelerator 4.0 Extended unit stores 40 million fingerprints, thus 2 units required to store the sample 60 million fingerprints database.
2. The response time for an identification request should satisfy project requirements. For example, the project requires receive an answer to an identification request in 1 second. Single MegaMatcher Accelerator 4.0 Extended unit matches 26 million fingerprint templates in 4-to-many mode, thus the two units will satisfy the project requirements for response time.
3. The peak hour request quantity should satisfy project requirements. For example, the project expects that there may be up to 15,000 identification requests per hour. Single MegaMatcher Accelerator 4.0 Extended unit matches 26 million fingerprint templates in 4-to-many mode, thus it will be able to process 6,240 requests per hour with the sample 15 million template database. Therefore, a cluster of 3 MegaMatcher Accelerator 4.0 Extended units will be required to process the required number of identification requests with the sample database.

Fault tolerance for a cluster of MegaMatcher Accelerators can be provided using these methods:

1. Spare MegaMatcher Accelerator units. A spare MegaMatcher Accelerator 4.0 unit "waits" until an operating unit fails and is used replace the failed one. Switching time from "wait" state to "operating" state depends on time required to copy database part used by failed node into spare node. If the failed node restored, it become the spare node.
2. Parallel clusters. A parallel "spare" cluster of MegaMatcher Accelerator 4.0 units may be run together with the main cluster and keep the data synchronized between the clusters. Both clusters can run in parallel and provide 2 times higher performance. If the main cluster becomes not available, the parallel cluster will continue operation and provide the nominal performance.

Go to MegaMatcher contents or MegaMatcher Accelerator contents