Usually you index and execute queries using primitive fields (long, float, string, etc). The fields may be within the root level of the space object, or embedded within nested objects within the space object. You may construct a query using a template object or SQL to specify the criteria you would like to use when the matching phase is performed within the space when looking for the relevant objects.
In some cases you might want to use a custom data type with a custom business logic to find matching objects within the space, rather the usual primitive data type comparison. To allow the space to invoke your business logic when the matching process is conducted, the Comparable interface should be implemented for a class that stores the data you would like to use with your custom business logic.
Such custom business logic might be useful when comparing vector data (2 dimensional Cartesian space). These may represent sound, maps, pictures or any other 2 or 3 dimensional artifacts. You may use this technique to query data based on any other mathematical or financial related formulas such as Time value of money like Present Value of a Cash Flow Series, Future Value of a Cash Flow Series, etc. Other areas where such custom matching is relevant, are Pattern recognition, Sequence analysis, Surveillance, Forensic, Social network behavior etc.
The Best Practices Custom Matching page includes a detailed example how you may use this technique to locate matching vectors stored within the space using the Euclidean distance formula:
Here is an example of a target vector, and a matching vector found using a custom matching implementation:
Such a custom matching implementation can locate a matching vector within few milisec where the space was storing 100,000 vectors.
Impressive – ha?
Shay Hassidim
