{"id":26412,"date":"2021-06-12T01:59:08","date_gmt":"2021-06-11T20:59:08","guid":{"rendered":"https:\/\/kmwllc.com\/?p=26412"},"modified":"2024-05-01T07:10:08","modified_gmt":"2024-05-01T02:10:08","slug":"solr-payload-inequalities","status":"publish","type":"post","link":"https:\/\/kmwllc.com\/index.php\/2021\/06\/12\/solr-payload-inequalities\/","title":{"rendered":"Solr Payload Inequalities"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\r\n\t\t\t\t\t\t
\r\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t
\r\n\t\t\t\t\t\t

<\/p>\n

<\/p>\n

<\/p>\n

Introduction<\/h2>\n

New in Solr\/Lucene 9.x is the ability to do inequality operations to search against payloads on terms.  Inequalities provide the ability to search for values that are greater than, less than, or equal to some threshold. <\/p>\n

<\/p>\n

<\/p>\n

As search and AI continue to  converge, one common use case is to be able to search for documents that have been classified by a machine learned model.  These models typically output a label and confidence score for each classification.  Documents can have many classifications associated with them that are generated from many different machine learned models.  <\/p>\n

<\/p>\n

<\/p>\n

The result is a data model where you have a document and a list of associated classifications.  Let\u2019s explore three different approaches to indexing and querying these documents and classifications along with a fourth approach using our recent contribution back to the Lucene and Solr Apache projects: the inequality payload query operator.<\/p>\n

<\/p>\n

<\/p>\n

We\u2019ll start with  a data model like the following which shows a relationship between a document and the document\u2019s associated classifications.<\/p>\n

<\/p>\n

<\/p>\n

\"\"<\/figure>\n

<\/p>\n

<\/p>\n

As each document is associated with zero or more classifications, each with their own label and confidence score, we are presented with the challenge to answer queries with the index to find something like the following:<\/p>\n

<\/p>\n

<\/p>\n

\u201cShow me all of the images that have a high confidence that they are of a person.\u201d<\/em><\/p>\n

<\/p>\n

<\/p>\n

For this example query, we\u2019ll take an example index that was created by running the COCO2017 image dataset through the Yolo and the VGG16 image classification neural networks.  The output classifications by either model represent the objects that were detected in the image.<\/p>\n

<\/p>\n

<\/p>\n

The VGG16 image provides classification of 1000 object types and their confidence levels.  The Yolo model provides us with 80 classes of objects that have been found with their confidence and additionally bounding box coordinates of where the image was found.<\/p>\n

<\/p>\n

<\/p>\n

Approach 1: Do it at index time<\/strong><\/p>\n

<\/p>\n

<\/p>\n

One common approach to answer this problem is to only tag the documents as being a \u201cperson\u201d if the classification was above a particular threshold.  Having a single field on the document for the \u201chigh confidence\u201d classifications is a perfectly valid approach.  The queries remain very simple, as they are just querying for a particular label in the classification field of the document.<\/p>\n

<\/p>\n

<\/p>\n

Example: <\/p>\n

<\/p>\n

<\/p>\n

high_confidence:person<\/em><\/p>\n

<\/p>\n

<\/p>\n

However, this will prevent the user from searching for documents with medium confidence labels.  To address this query, the indexing of the documents could stamp two fields, one with \u201chigh confidence\u201d labels and another with \u201cmedium confidence\u201d labels.  <\/p>\n

<\/p>\n

<\/p>\n

Then you can search the \u201cmedium confidence\u201d field or the \u201chigh confidence\u201d field for the label in question.  The trade off here is that at query time  a search across multiple fields is required. As requirements for the  confidence filter become more granular, additional bucketed fields need to be created.  If the definition of those confidence levels changes the documents would need to be re-indexed to recompute the proper labels for the proper bucket.  This approach works only if the definition of high confidence label is known up front and will never change.<\/p>\n

<\/p>\n

<\/p>\n

Example:<\/p>\n

<\/p>\n

<\/p>\n

high_confidence:person OR medium_confidence:person<\/em><\/p>\n

<\/p>\n

<\/p>\n

In reality, users want the ultimate flexibility to decide what they consider a high confidence classification.  User interfaces might even want to present this as a slider control in a search UI.<\/p>\n

<\/p>\n

<\/p>\n

Approach 2 Do it at query time with a field for the labels<\/strong><\/p>\n

<\/p>\n

<\/p>\n

To avoid having to re-index all the documents when the definition of high confidence changes, there are  a few viable options at query time  to solve this problem.  <\/p>\n

<\/p>\n

<\/p>\n

One approach is to store the confidence score for each label generated by the models in separate fields on the document, one field per label. <\/p>\n

<\/p>\n

<\/p>\n

Once the documents are indexed with a field for each label\u2019s score, a range search can be executed on the field that corresponds to the label that is being searched.   In the above example query, searching for documents that have a \u201cperson\u201d with high confidence could be implemented as a range search on the \u201cperson\u201d field.<\/p>\n

<\/p>\n

<\/p>\n

For example:  <\/p>\n

<\/p>\n

<\/p>\n

person:[0.75 TO *]<\/em><\/p>\n

<\/p>\n

<\/p>\n

This approach has its drawbacks as well in that you might have multiple persons detected in an image, each with their own confidence level.  So at best, you could choose the highest confidence level of the person classification and use that for search purposes or potentially use a multi-valued field to represent each score.<\/p>\n

<\/p>\n

<\/p>\n

An additional drawback is that each possible label requires an additional field in the index.  This approach could use dynamic fields unless all of the possible labels are be known up front.  Some models might classify thousands of different object types.  This would result in  an explosion in the number of fields in the index.  Aside from the potential for the number of fields to become unruly, the UI and query language would also need to know how to map the label to the appropriate field name to properly construct that query.<\/p>\n

<\/p>\n

<\/p>\n

Approach 3:  Use joins to perform the filtering<\/strong><\/p>\n

<\/p>\n

<\/p>\n

The next possible approach is to index each classification as a child document and do parent\/child join queries against Solr.  There is a join query parser in Solr that allows for all sorts of database-like join queries between two queries.  These queries allow for relational queries between two different datasets.  As wonderful as that sounds, (and it is wonderful!) there are some limitations and drawbacks to this approach.  The first and most notable is that if you have a multi-shard index, special attention needs to be paid to how the documents are routed to the shards of the index.  The key constraint for the parent\/child document queries is that the documents need to be routed to the shards based on the value of their join key.<\/p>\n

<\/p>\n

<\/p>\n

In this approach a document is indexed to represent each classification that is generated for the document being classified.  Every document in the index will have zero or more classification documents that relate to it.  For some applications it\u2019s ok to change how the routing is working, but depending on the query use cases, this might not be possible.  <\/p>\n

<\/p>\n

<\/p>\n

The second notable drawback to the join query approach is that it is comparatively slow and very expensive to execute as compared to other simpler term and range queries.<\/p>\n

<\/p>\n

<\/p>\n

Lastly, the join query potentially introduces a large number of additional documents to the index.  This will impact the overall search latency for any given query.  Query latency is proportional to the number of documents per shard in an index.  So, the introduction of all the classification documents will affect the cluster sizing, as now the index should be sized to support the additional documents.  That typically means more shards and potentially servers with additional CPUs.<\/p>\n

<\/p>\n

<\/p>\n

The basic approach is to search on classifications but return the parent document. <\/p>\n

<\/p>\n

<\/p>\n

Search all documents that have a child document that contains a label of \u201cfoo\u201d with a confidence greater than 0.75.<\/p>\n

<\/p>\n

<\/p>\n

For example:<\/p>\n

<\/p>\n

<\/p>\n

{!join to=”id” from=”parent_id” v=”+label:foo +confidence:[0.75 TO *]”}<\/em>  <\/p>\n

<\/p>\n

<\/p>\n

Approach 4:  New & improved inequality payload support!<\/strong><\/p>\n

<\/p>\n

<\/p>\n

Upon review, it seemed that an alternative approach to use payloads might be able to solve this problem.  The payload_check query parser in Solr provides access to the SpanPayloadCheckQuery.  This Lucene query provides access to the payload data while matching.  Once the term has been matched, the payload is then checked to see if it\u2019s actually a match.  This functionality was used to support things like part of speech tagging for terms.  It allowed developers to use a delimited payload field in the Solr schema.  The values in that field could then be encoded with the term and a value delimited by a pipe.<\/p>\n

<\/p>\n

<\/p>\n

An example of Part of Speech tagged text using the delimited payload:<\/p>\n

<\/p>\n

<\/p>\n

Lucene|NOUN is|VERB awesome|ADJ<\/p>\n

<\/p>\n

<\/p>\n

In addition to the payloads being strings, an integer or a floating point number can be stored there and encoded like:<\/p>\n

<\/p>\n

<\/p>\n

Person|0.82 Cat|0.75 Monitor|0.55<\/p>\n

<\/p>\n

<\/p>\n

The only missing piece to being able to use this for the AI model classification search was the ability to do a range search on the payload instead of just an equals operation.<\/p>\n

<\/p>\n

<\/p>\n

We had the pleasure of recently contributing this capability back to Lucene and Solr.  The patch includes the ability to provide an operation while matching now to support common operations such as greater than, less than, in addition to the equals operator.  We\u2019re happy to see that it will be included in the upcoming Solr 9.0 release.  <\/p>\n

<\/p>\n

<\/p>\n

So, now we can express the desired query as:<\/p>\n

<\/p>\n

<\/p>\n

{!payload_check f=”classifications_dpfs” op=”gt” payloads=”0.75″ v=”Person”}<\/p>\n

<\/p>\n

<\/p>\n

The new payload check query parser allows the user to specify the operation and the payload value to use as the reference for that operation.  The above example searches the \u201cclassifications_dpfs\u201d field for any classification of \u201cPerson\u201d where the payload has a value greater than 0.75.  <\/p>\n

<\/p>\n

<\/p>\n

So, with this last option we can use the payload check query parser in Solr to allow us to search for labels from the classification model that are above a threshold confidence score.  <\/p>\n

<\/p>\n

<\/p>\n

The ultimate result here is that we get the full ability to search on a term with one additional dimension of metadata filtering.  Term and Payload.  This unlocks a lot of other possibilities when it comes to image search.<\/p>\n

<\/p>\n

<\/p>\n

One possible example is to put the number of people found as a payload.  Yolo can detect multiple objects in a scene, so the user could search for something like:<\/p>\n

<\/p>\n

<\/p>\n

\u201cAt least 2 people and a tennis racket.\u201d<\/p>\n

<\/p>\n

<\/p>\n

Having the classifier output from Yolo in the following format:<\/p>\n

<\/p>\n

<\/p>\n

Person|2 Tennis_Racket|1 <\/p>\n

<\/p>\n

<\/p>\n

A similar approach can be taken if you want to encode the center point X and Y coordinates. This would enable searches like: <\/p>\n

<\/p>\n

<\/p>\n

\u201cFind me a picture with a Person on the left and a Pizza on the right.\u201d<\/p>\n

<\/p>\n

<\/p>\n

The capabilities increase further when you start putting together scene labels along with object classification, like:  <\/p>\n

<\/p>\n

<\/p>\n

Yolo + VGG16 to get context in the search results.<\/p>\n

<\/p>\n

<\/p>\n

By combining these two computer vision models we can start asking questions beyond what Yolo alone can answer.   <\/p>\n

<\/p>\n

<\/p>\n

\u201cShow me a picture of at least 2 people skiing\u201d <\/p>\n

<\/p>\n

<\/p>\n

Yolo will detect the number of people and the VGG16 model detects the act of skiing.<\/p>\n

<\/p>\n

<\/p>\n

Benchmarks<\/strong><\/p>\n

<\/p>\n

<\/p>\n

First, some notes about how the benchmarks were generated:<\/p>\n

<\/p>\n

<\/p>\n

Each of the 4 approaches has the same configset.  All cache sizes (except for the perSegment cache) were set to zero size. All indices in the test were a single shard with one segment and no deleted documents.  All of the indices represent 1,000,000 documents.  Each document has an average of 50 classifications associated with it.  Each classification has a random confidence score from 0 to 1.  <\/p>\n

<\/p>\n

<\/p>\n

Approach 1 Document Example: A multi-valued field that contains only the labels that had a confidence score greater than 0.75.<\/p>\n

<\/p>\n

<\/p>\n

{ <\/strong><\/p>\n

<\/p>\n

<\/p>\n

  \"id<\/strong>\":\"doc_78375\",
  \"classification_ss<\/strong>\":  [\"label_7792\",\"label_9689\",\"label_2049\",\"label_6581\",
                         \"label_4795\",\"label_1780\",\"label_6323\",\"label_4939\",
                         \"label_8818\",\"label_877\",\"label_8524\",\"label_3159\",
                         \"label_4776\",\"label_1276\",\"label_7104\",\"label_4335\",
                         \"label_108\",\"label_5675\",\"label_424\",\"label_7745\",
                         \"label_4144\",\"label_2712\",\"label_4782\",\"label_9894\",
                         \"label_2777\",\"label_1267\",\"label_8919\",\"label_5332\",
                         \"label_7159\",\"label_4139\",\"label_6714\"]}<\/pre>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Approach 2 Document Example: A document with a field for each label containing the value of the confidence score for that label.<\/p>\n
<\/p>\n
<\/p>\n
{
<\/strong>  \"id\":<\/strong>\"doc_doc_20295\"<\/strong>,
<\/strong>  \"label_264_fs\":[<\/strong>0.5059256<\/strong>],
<\/strong>  \"label_4777_fs\":[<\/strong>0.8075591<\/strong>],
<\/strong>  \"label_5773_fs\":[<\/strong>0.6512147<\/strong>],
<\/strong>  \"label_6584_fs\":[<\/strong>0.44860387<\/strong>],
<\/strong>  \"label_5053_fs\":[<\/strong>0.77677464<\/strong>],
<\/strong>  \"label_2307_fs\":[<\/strong>0.99134594<\/strong>],
<\/strong>  \"label_9447_fs\":[<\/strong>0.6198554<\/strong>],
<\/strong>  \"label_1534_fs\":[<\/strong>0.993752<\/strong>],
<\/strong>  \"label_2489_fs\":[<\/strong>0.3812973<\/strong>],
<\/strong>  \"label_1578_fs\":[<\/strong>0.67712253<\/strong>],
<\/strong>  \"label_7583_fs\":[<\/strong>0.9276807<\/strong>],
<\/strong>  \"label_796_fs\":[<\/strong>0.9256864<\/strong>],
<\/strong>  \"label_345_fs\":[<\/strong>0.21647614<\/strong>],
<\/strong>  \"label_8326_fs\":[<\/strong>0.42797613<\/strong>],
<\/strong>  \"label_6023_fs\":[<\/strong>0.16159433<\/strong>],
<\/strong>  \"label_3220_fs\":[<\/strong>0.82546365<\/strong>],
<\/strong>  \"label_4067_fs\":[<\/strong>0.940214<\/strong>],
<\/strong>  \"label_932_fs\":[<\/strong>0.71239257<\/strong>],
<\/strong>  \"label_7323_fs\":[<\/strong>0.33341646<\/strong>],
<\/strong>  \"label_5203_fs\":[<\/strong>0.072936356<\/strong>],
<\/strong>  \"label_8474_fs\":[<\/strong>0.6330075<\/strong>],
<\/strong>  \"label_2032_fs\":[<\/strong>0.45183575<\/strong>],
<\/strong>  \"label_6371_fs\":[<\/strong>0.8656315<\/strong>],
<\/strong>  \"label_3488_fs\":[<\/strong>0.052257597<\/strong>],
<\/strong>  \"label_4137_fs\":[<\/strong>0.15416396<\/strong>],
<\/strong>  \"label_6509_fs\":[<\/strong>0.52511454<\/strong>],
<\/strong>  \"label_8989_fs\":[<\/strong>0.41732424<\/strong>],
<\/strong>  \"label_1067_fs\":[<\/strong>0.45847535<\/strong>],
<\/strong>  \"label_5892_fs\":[<\/strong>0.9040163<\/strong>],
<\/strong>  \"label_8169_fs\":[<\/strong>0.26057434<\/strong>],
<\/strong>  \"label_3524_fs\":[<\/strong>0.26224774<\/strong>],
<\/strong>  \"label_4912_fs\":[<\/strong>0.037523687<\/strong>],
<\/strong>  \"label_3772_fs\":[<\/strong>0.587384<\/strong>],
<\/strong>  \"label_3116_fs\":[<\/strong>0.2450012<\/strong>],
<\/strong>  \"label_5069_fs\":[<\/strong>0.70538366<\/strong>],
<\/strong>  \"label_5939_fs\":[<\/strong>0.90539235<\/strong>],
<\/strong>  \"label_3369_fs\":[<\/strong>0.4885615<\/strong>],
<\/strong>  \"label_3798_fs\":[<\/strong>0.35722762<\/strong>],
<\/strong>  \"label_5111_fs\":[<\/strong>0.3300156<\/strong>],
<\/strong>  \"label_1684_fs\":[<\/strong>0.18698442<\/strong>],
<\/strong>  \"label_6735_fs\":[<\/strong>0.7144106<\/strong>],
<\/strong>  \"label_7830_fs\":[<\/strong>0.79478115<\/strong>],
<\/strong>  \"label_3240_fs\":[<\/strong>0.7042537<\/strong>],
<\/strong>  \"label_2410_fs\":[<\/strong>0.09114766<\/strong>],
<\/strong>  \"label_5419_fs\":[<\/strong>0.83966637<\/strong>],
<\/strong>  \"label_4207_fs\":[<\/strong>0.0035191178<\/strong>],
<\/strong>  \"label_4484_fs\":[<\/strong>0.5441104<\/strong>],
<\/strong>  \"label_6761_fs\":[<\/strong>0.69559073<\/strong>],
<\/strong>  \"label_2117_fs\":[<\/strong>0.39736092<\/strong>],
<\/strong>  \"label_1298_fs\":[<\/strong>0.8430424<\/strong>],
<\/strong>  \"label_5847_fs\":[<\/strong>0.22964293<\/strong>],
<\/strong>  \"label_3950_fs\":[<\/strong>0.6538746<\/strong>],
<\/strong>  \"label_6558_fs\":[<\/strong>0.69730353<\/strong>],
<\/strong>  \"label_1273_fs\":[<\/strong>0.024785161<\/strong>],
<\/strong>  \"label_3927_fs\":[<\/strong>0.0013412237<\/strong>],
<\/strong>  \"label_1759_fs\":[<\/strong>0.75639284<\/strong>],
<\/strong>  \"label_3553_fs\":[<\/strong>0.5268485<\/strong>],
<\/strong>  \"label_5143_fs\":[<\/strong>0.8450275<\/strong>],
<\/strong>  \"label_9301_fs\":[<\/strong>0.12585384<\/strong>]}<\/strong><\/pre>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Approach 3 Example Document:  One document that represents the record being classified and an additional document for every classification associated with that document.  The total number of documents in this index was 1,000,000 for the parent documents and 50,485,334 documents for each of the classification records.<\/p>\n
<\/p>\n
<\/p>\n
# Example Parent Document<\/strong><\/p>\n
<\/p>\n
<\/p>\n
{
<\/strong>  \"id\":<\/strong>\"doc_729413\"
<\/strong>}<\/strong><\/pre>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
# Example Classification Document (on average 50 of these for each parent document.)<\/strong><\/p>\n
<\/p>\n
<\/p>\n
{
<\/strong>  \"id\":<\/strong>\"doc_729413_5\"<\/strong>,
<\/strong>  \"parent_id_s\":<\/strong>\"doc_729413\"<\/strong>,
<\/strong>  \"label_s\":<\/strong>\"label_4067\"<\/strong>,
<\/strong>  \"confidence_f\":<\/strong>0.21850449
<\/strong>}<\/strong><\/pre>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Approach 4 Example Document: A document with a single field containing all classification labels with the confidence level encoded as a payload.<\/p>\n
<\/p>\n
<\/p>\n
{
  \"id<\/strong>\":\"doc_doc_333114\",
  \"class_dpfs<\/strong>\":[\"label_6872|0.7949082\",\"label_3550|0.22995031\",
                \"label_7561|0.66999483\",\"label_3575|0.76349306\",
                \"label_6567|0.29170412\",\"label_9300|0.22878802\",
                \"label_7146|0.15249991\",\"label_7853|0.26775044\",
                \"label_9330|0.69193286\",\"label_315|0.3812859\",
                \"label_9941|0.60243666\",\"label_5448|0.4909597\",
                \"label_3898|0.2772404\",\"label_3798|0.58473474\",
                \"label_1040|0.39535648\",\"label_3017|0.5128221\",
                \"label_5611|0.1511501\",\"label_7777|0.93621653\",
                \"label_6589|0.48112237\",\"label_6023|0.69422346\",
                \"label_6525|0.49891192\",\"label_6580|0.41795957\",
                \"label_6807|0.5424252\",\"label_6233|0.3097676\",
                \"label_624|0.9763578\",\"label_1726|0.3847112\",
                \"label_9139|0.5317108\",\"label_6330|0.64640564\",
                \"label_2413|0.24439555\",\"label_1372|0.17762291\",
                \"label_562|0.3614515\",\"label_7828|0.7642365\",
                \"label_3786|0.19018763\",\"label_9409|0.75261647\",
                \"label_619|0.18773353\",\"label_3496|0.4446562\",
                \"label_3556|0.43172425\",\"label_7278|0.5559282\",
                \"label_6851|0.42342138\"]}<\/pre>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Benchmark Results<\/h3>\n
<\/p>\n
<\/p>\n
Index Comparison <\/h4>\n
<\/p>\n
<\/p>\n
\n\n\n\n\n\n\n\n
Metric<\/strong><\/td>\nApproach 1<\/strong><\/td>\nApproach 2<\/strong><\/td>\nApproach 3<\/strong><\/td>\nApproach 4<\/strong><\/td>\nComments<\/strong><\/td>\n<\/tr>\n
DPS<\/td>\n11761<\/td>\n209<\/td>\n409<\/td>\n3566<\/td>\nDocuments indexed on a single thread generating random data.  Updates batched, no committing while feeding content.  Only a single replica active.<\/td>\n<\/tr>\n
Index Size<\/td>\n219.32<\/td>\n906.99<\/td>\n2610<\/td>\n1220<\/td>\nSize in MB<\/td>\n<\/tr>\n
Memory<\/td>\n1772<\/td>\n1361108<\/td>\n5556<\/td>\n1460<\/td>\nAs reported from solr admin gui<\/td>\n<\/tr>\n
Test Query<\/td>\nclassification_ss:label_7792<\/td>\nlabel_7792_fs:[0.75 TO *]<\/td>\n{!join from=”parent_id_s” to=”id” v=”+label_s:label_7792 +confidence_f:[0.75 TO *]”}<\/td>\n{!payload_check op=”gt” f=”class_dpfs” payloads=”0.75″}label_7792<\/td>\nExample syntax<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n
<\/p>\n
<\/p>\n
Indexing Benchmark Commentary<\/strong><\/p>\n
<\/p>\n
<\/p>\n
There are some interesting takeaways from this benchmark.  <\/p>\n
<\/p>\n
<\/p>\n
Indexing Performance<\/p>\n
<\/p>\n
<\/p>\n