A shortestPath Streaming Expression was added that implements a distributed breadth-first graph traversal to find the shortest paths in a directed directed graph.
Passing update.chain=tolerant will use the processor chain defined above. One can also pass maxErrors=10 to limit the number of errors before aborting the complete update request. For example, if one is loading a large CSV file with millions of entries for the first time, it may be useful to abort early if every addition would fail due to a configuration error.
Filter creation for small cardinality sets (those that match few documents) now produces much less garbage. Up to 3x performance producing small sets (due to less GC overhead).
The now deprecated trie-based numeric fields use (and abuse) the full-text index to index parts of numbers to speed up range queries. The new Points-based numeric fields do not use the full-text index, but instead have a dedicated index structure designed specifically for multidimensional ranges over numbers: the BKD tree. The BKD tree index structure is smaller and faster for range queries, but is slightly slower for exact match queries.
Since Point fields do not currently support un-inversion (i.e. FieldCache), some search functionality requires that points have docValues enabled for fast per-document lookups. This includes sorting, function queries, {!graph}, and {!join} queries.
Current template schemas define types like the following:
Interested in how the underlying BKD data structure works? Here’s a great lesson from Robert Sedgewick, Princeton University on KD trees (BKD trees are just a variant of KD trees):
The JSON Facet API has a new parameter called refine that turns on two-phase refinement of partial facets during distributed faceting. This guarantees that the statistics (counts or other metrics) within returned facet buckets are accurate.
Partial facets are those facets that specify a limit and thus may not return all facet buckets from all shards in a distributed search. If refine is set to true on one of these partial facets, a second phase is used to “refine” the top buckets from the first phase, collecting information from other shards that did not yet contribute to those buckets. Without refinement, counts and statistics for the bucket can be incorrect. The second phase of faceting normally does not cause any additional HTTP requests since they are piggy-backed onto the normal second phase of distributed search that retrieves stored fields for the top document ids.
NRT stands for Near Real Time. This is the default and original replica type in SolrCloud. Updates flow from the leader to all replicas and are added to replica transaction logs as well as indexed. This is the only type of replica to support soft commits since TLOG and PULL replicas need hard commits to copy over new index segments.
Updates flow from the leader to all replicas and are added to replica transaction logs (tlogs) only. Replicas are kept up-to-date by pulling new index segment files from the leader. The transaction logs allow these replicas to recover and become a leader if necessary, as well as directly service real-time get requests.
Updates do not flow from the leader to replicas. Replicas are kept up-to-date by pulling new index segment files from the leader. This is similar to the original non-SolrCloud master-slave replication. Replicas of this type may not become leaders since updates would most likely be lost. Real-time get requests to a PULL replica are forwarded to the leader since these replicas lack transaction logs to find the most recent uncommitted updates.
The default response format has been changed from XML to indented JSON. Add wt=xml to the request obtain an XML response, and add indent=off if you wish to turn off indenting.
The new v2 API, exposed at /api/ is now the preferred API (esp for using the collections API), but /solr/ continues to be supported.
The alternate “Analytics Component” in the contrib modules was bumped to v2, with distributed support and a new JSON-based request syntax
Auto-scaling framework that allows Solr to place new replicas based on metrics such as free disk space.
The standard lucene/solr query parser now defaults to sow=false, meaning that for text fields, it does not split on whitespace before handing the text to the analyzer. This enabled multi-word synonyms to be matched by the analyzer.
When a collection is created without specifying a configset, the new ‘_default’ configset is now used. It is data-driven (schemaless), and indexes strings as analyzed text in addition to using a copyField to *_str field suitable for sorting or faceting.
Parallel SQL queries across SolrCloud collections. The SQL engine is built on top of Solr’s Streaming API (Streaming Expressions), which provides support for parallel relational algebra and real-time map-reduce.
SQL statements are compiled to Streaming Expressions for parallel execution across SolrCloud worker nodes.
SolrCloud collections are abstracted as Relational Tables.
Full support for Lucene/Solr query syntax in the WHERE clause.
Many operations such as grouping/rollups can be automatically parallelized, utilizing the real-time MapReduce capabilities of the streaming expressions.
Grouping/rollup operations can be pushed down and leverage the JSON Facet API for increased performance.
Currently works in SolrCloud mode only… no standalone mode yet.
SQL functionality is currently experimental and incomplete (for example underlying streaming join functionality is still in the process of being integrated.)
Examples:
select category, count(*), sum(inventory), min(price), max(price), avg(outstanding) from collection1 where text='4k HDTV' group by category order by sum(inventory) asc limit 10
select id,category from collection1 where category = '(dvd OR bluray)' order by category desc limit 100
Solr has a new JDBC driver that may be used to access the new SQL functionality. The Solr JDBC driver has been tested with DbVisualizer, Apache Zeppelin, and SQuirreL SQL so far.
The general form of the JDBC connection string is:
A basic graph traversal query that follows nodes to edges, optionally filtering during traversal.
Example: Assume we have documents that represent people, and each document has a field called “parent_id” which lists the parents. This example query matches “Philip J. Fry” and all of his ancestors:
fq={!graph from=parent_id to=id}id:"Philip J. Fry"
The main argument to the graph query defines the root set, in this case id:"Philip J. Fry". The graph query then iteratively follows the parent_id field to documents with corresponding id fields (i.e. for each iteration, the values for parent_id in the current set are matched to id field of all documents). The basic graph query is equivalent to a repeated join query.
Graph query parameters:
from
- The field used in the current set of documents to match to the to field in the set of destination documents.- to
- The field used to find matches in the values obtained from the from fields of the starting set of documents.- traversalFilter - A filter query that is applied on each iteration.
returnRoot - Controls whether the root set of documents should be included. Defaults to “true”.
returnOnlyLeaf - If true, only returns leaf documents. Defaults to “false”.
maxDepth - The maximum number of iterations before graph traversal stops. Defaults to -1 (unlimited).
NOTE: This graph query only traverses edges in the same index (i.e. it does not traverse edges across different nodes/cores). Distributed graph traversal is being developed and will be in future versions of Solr 6.x
For those new to full-text search terminology, “similarity” produces a score for how similar a document is to a full-text query. When determining this score, document statistics as well as corpus statistics are used. Some scoring factors include:
The number of times a search term appears in the document field. More matches produces a higher score.
The size of the document field. Longer fields produce a lower score, with the idea being that for a given number of term matches, shorter is better (more specific match)
The average length of the field across the entire corpus (BM25 considers this, classic tf-idf does not)
How common the query terms are across the entire corpus. The idea being that rarer terms carry more information. For example, if I searched for “blue whale”, all else being equal, I’d probably want things about whales to score higher than things about blue.
An experimental version of CDCR (Cross Data Center Replication) has been added that supports an active-passive configuration.
Updates are asynchronously sent from the active cluster leader to the passive cluster leader. Since updates are asynchronously relayed from the leader’s transaction logs, temporary connectivity issues between data centers can be tolerated with no interruption in service for the primary DC.
Here is the in-progress CDCR documentation. The documentation link is likely to change once CDCR moves out of it’s “experimental” phase.
In previous Solr versions, returning the top N documents only retrieved field values from the row-store (i.e. fields where “stored” is true). Values will now also be retrieved from docValues (which are essentially column stored) for fields where “stored” is false. This avoids the need to duplicate the value in the row store if it’s already column stored.
A "facet-trace" section has been added to the debug info for JSON Facets. The exact format is subject to change, but the current information includes information about each facet command, including the processor used to execute the facet and the domain size. This information is included recursively included for each facet bucket for facets with sub-facets.
facet.method=uif parameter causes traditional field faceting to delegate to the JSON Facet API with method=uif. This is roughly equivalent to what the Solr 4 default faceting method was for multi-valued fields. It is optimized for performance over static indexes rather than NRT (quickly changing indexes).
The compression mode for stored fields can now be specified via codecFactory in solrconfig.xml See the Codec Factory section in the Solr reference guide for more details.
Generic support was added for making collection APIs async. Async support was added for the following commands: delete/reload collection, create/delete alias, create/delete shard, delete replica, add/delete replica property, add/remove role, overseer status, balance shard unique, rebalance leaders, modify collection, migrate state format.
There is a new experimental BlockJoinFacetComponent for calculating facets by a child.facet.field parameter with a {!parent} query. The component is not enabled by default. Note that this component is unrelated to the block join faceting support in the JSON Facet API.
The XML query parser, registered as “xmlparser” is a direct interface to Lucene’s XMLQueryParser (CoreParser). Personal recommendation: avoid the use of this query parser unless you have very unusual/specific needs.
This parser does not do any text analysis on terms, so provided terms will need to match what is in the index exactly (i.e. you will need to do things like lowercasing and stemming yourself). Good backward compatibility is unlikely with this parser as it exposes more internal implementation details. Term queries on fields such as numeric fields, enum fields, and boolean fields will only work if you know the internal term representation in the index.
See XmlQParser in the Solr ref guide for more info.
A configset, or configuration set, is a set of config files for a Solr collection. For SolrCloud mode, an upconfig option has been added to the /bin/solr script to upload a configset to zookeeper. A matching downconfig option has been added to download a configset from zookeeper.
There is an internal CheckHdfsIndex class that can be run from the command line for HDFS indexes like CheckIndex can be run for normal indexes. Example:
Multi-select faceting is a powerful faceting style that allows users to see and select multiple facet constraints (facet values) for certain facets. This example uses Solr’s JSON Facet API along with filter tagging and excluding to implement this style of faceting.
Let’s say we have 3 facets, Size, Color, and Brand. This is multi-select faceting because for the Color and Brand facets, we want the user to be able to select multiple constraints (values). The Size facet is single-select since we’ve decided that customers in general will only be interested in one size at a time.
Here is our super-fancy ASCII UI, after the user has searched for "running shorts":
=== Size === === Color === === Brand ===
[Small] (7) [ ] Red (2) [ ] Nike (7)
[Medium] (5) [ ] Blue (8) [ ] Adidas (5)
[Large] (6) [ ] Green (3) [ ] Reebok (4)
[ ] Black (5) [ ] Under Armour (2)
(Top matches sorted by popularity displayed here... use your imagination!)
Note that the Color and Brand facets have checkboxes to indicate which constraints have been selected. We’re starting off with no constraints. Below the facets is where we would display the top matching items, along with pretty pictures, prices, etc.
The user selects “Blue” so we add that as a filter and re-issue the request (we’re using Solr’s JSON Facet API):
&q="running shorts"
&fq=color:Blue
&json.facet={
sizes:{type:terms, field:size},
colors:{type:terms, field:color},
brands:{type:terms, field:brand}
}
We get back the response and update our UI from that data:
=== Size === === Color === === Brand ===
[Small] (3) [ ] Red (0) [ ] Nike (3)
[Medium] (2) [x] Blue (8) [ ] Adidas (2)
[Large] (3) [ ] Green (0) [ ] Reebok (2)
[ ] Black (0) [ ] Under Armour (1)
(Top Blue running shorts displayed here)
What’s right: The Size and Brand facets now reflect the fact that we’ve selected Blue, and that’s what we wanted. Our list of top matches also only includes Blue things, just as we wanted.
What’s wrong: Because we filtered out anything that wasn’t Blue, we get back 0 counts for other colors! But we still want the other color information so the customer can select additional colors.
When we compute the multi-select Color facet, we want to ignore any constraints (filters) on that facet so we will get back the correct counts for other colors. To accomplish this, we can tag filters and then selectively exclude filters (i.e. pretend they don’t exist) by tag when faceting.
The same thing applies to the multi-select Brand facet… we want any Brand selections to affect everything else (including all other facets), except for the Brand facet itself.
When the user selects Blue, we add that as a filter tagged with COLOR and re-issue the request:
The domain is the set of documents that facets will be calculated over. In the JSON Facet API, the domain keyword/command is normally used to change the domain before the facets are calculated.
In our example above, we specified domain:{excludeTags:COLOR} for the colors facet. This will re-calculate the facet domain as if any filters tagged with COLOR were not applied.
We naively add an additional filter, fq={!tag=COLOR}color:Black to the request, just as we would with traditional single-select faceting.
What’s wrong: Everything! Our request matches nothing and we get back all 0’s.
This is because filters are logically intersected. We searched for things that were Blue AND Black, and that will match nothing (assuming our items only have a single color). What we really want is Blue OR Black.
Although our simple example just dealt with facet counts, multi-select faceting via excludeTags works with the broad range of features in the JSON Facet API. The domain change will apply to everything else under that facet, including Sub-facets and Facet Functions.
Solr filter queries (fq parameters) can be tagged with arbitrary strings using the localParams {!tag=mystring} syntax. Example: fq={!tag=COLOR}color:Blue
Multiple filters can be tagged with the same tag. Example: fq={!tag=foo}one_filter&fq={!tag=foo}another_filter
A single filter may be tagged with multiple tags. Example: fq={!tag=tag1,tag2,tag3}my_field:my_filter
During faceting, the facet domain may be changed to exclude filters that match certain tags via the excludeTags keyword. It’s as if the filter was never specified for that specific facet. This is useful for implementing multi-select faceting Example: colors:{type:terms, field:color, domain:{excludeTags:COLOR}}
excludeTags can be multi-valued comma-separated string. Example: excludeTags:"tag1,tag2"
excludeTags can be a JSON array of tags. Example: excludeTags:["tag1","tag2"]
One can exclude tags that are not used in the current request. This makes constructing requests simpler since you don’t need to worry about changing the faceting part of the request based on what filters have been applied.
For nested facets, excludeTags can appear at any level of the hierarchy. They do not currently “stack” though. If a parent facet has excludeTags:tag1 and a child facet wants to additionally exclude tag2 filters, then they must currently do so explicitly with excludeTags:“tag1,tag2”. Nested exclusions are experimental and subject to change.
A filter query retrieves a set of documents matching a query from the Solr filter cache. This improves performance of additional queries that use the same filter clauses. All documents matching the query produce a score of 0 by default, but this can be changed by specifying a boost.
Filter Query Example:
description:HDTV OR filter(+promotion:tv +promotion_date:[NOW/DAY TO NOW/DAY+7DAY])
Multi-valued fields with docValues (as well as binary docValues fields), previously had an on-heap index structure pointing to the on-disk (i.e. off-heap) values. This index has been moved off-heap, and directly read as needed from the index file.
Sparse docValues fields with less than 1% of documents containing a value in the field, are now internally encoded with a new SPARSE_COMPRESSED method to save storage space.
Terms/field faceting has a new parameter called “method” to give an execution hint while faceting on a field.
method:uif - Stands for UninvertedField, a method of faceting indexed, multi-valued fields using top-level data structures that optimize for performance over NRT capabilities.
method:dv - Stands for DocValues, a method of faceting indexed, multi-valued fields using per-segment data structures. This method mirrors faceting on real docValues fields but works by building on-heap docValues on the fly from the index when docValues aren’t available. This method is better for a quickly changing index.
method:stream - This method creates each individual facet bucket (including any sub-facets) on-the-fly while streaming the response back to the requester. Currently only supports sorting by index order.
NOTE: currently, if a field is indexed with docValues, the dv method will be used even if method:uif is specified.
Faceting on DocValue fields and single-valued fields with the new Facet Module (JSON Facet API), has been optimized. When sorting by count, and when there are multiple hits expected per bucket, per-segment ords are collected before being mapped to global ords.
This optimization applies to the following field types:
single-valued and multi-valued string fields with docValues
indexed single-valued string fields
indexed multi-valued string fields, when facet.method=dv is used
Here’s an example of the speedups obtained when faceting over 5M documents on different single-valued fields:
A collection API command MIGRATESTATEFORMAT that will migrate from an older-style shared clusterstate.json in Zookeeper, to per-collection cluster state files (state.json per collection).
An expert-level FORCELEADER command has been added to help manually recover from a rare scenario where it looks like there are no replicas for a shard suitable to become the leader (i.e. when all of them are marked as recovering).
See Force Leader in the collections API section of the Solr reference guide.
A 100% accurate count of distinct values (count distinct) is not generally possible without actually observing all of the values together. However there are a number of ways to estimate the count.
The uniquefacet function is Solr’s fastest implementation to calculate the number of distinct values. It always provides exact counts on a single Solr node. For distributed search over multiple nodes, it provides exact counts when the number of values per node does not exceed 100 (by default).
When the number of unique values does exceed 100 in any given shard, the following algorithm is used:
It estimates the count by sending the top 100 results from each shard along with the total exact “unique” count for each shard.
totalSeen is the number of actual results we saw from all shards (i.e. not deduped yet).
uniqueSeen is the number of unique values we saw from all shards (i.e. deduped).
notSeen is the number of unique values from each shard that were not sent (because of the 100 cutoff).
factor = uniqueSeen / totalSeen (i.e. what fraction of values that we saw were unique)
estimate = uniqueSeen + ( notSeen * factor ) (i.e. we simply apply the factor to the number of values we didn’t see)
(New in Solr 5.2) The HyperLogLog algorithm was developed as an advanced statistical method of estimating the distinct number of values without using too much memory. It does add more calculation overhead however, and is thus slower than Solr’s “unique” facet function.
HyperLogLog requires very high quality hashes for accurate estimation. Solr uses a port of MurmurHash3 for Java to calculate these hashes.
The Facet Analytics Module and the older Stats component both have support for HyperLogLog as of Solr 5.2
This first test facets on the multi-valued string field m100_5_ss (it has up to 5 values per field, and 100 unique values in total). Then for the top 10 buckets, the cardinality of the single-valued string field (the “stat field”) is calculated. The chart below shows performance for different number of unique values in the stat field.
This next test reverses the 2 fields above, first faceting on the single valued string field s100_s (it has 100 unique values in total) and then calculating cardinality over multi-valued string fields with different numbers of unique values in the index.
The last test facets on the integer field s100_i and then calculates cardinality over another integer field with varying number of unique terms in the index.
The JSON Facet API can now change the domain for facet commands, essentially doing a block join and moving from parents to children, or children to parents before calculating the facet data.
For example, if you indexed chapters with pages as nested child documents, then you could map from chapters to pages before faceting by adding the following parameter to the facet command:
domain : { blockChildren : "type:chapter" }
Or if you started with pages, you could map to chapters with
domain : { blockParent : "type:chapter" }
Note that in both cases, we provide the parent filter (how parent documents are defined) of “type:chapter” regardless of which direction we are mapping.
See this Nested Objects tutorial for complete examples of combining faceting and block join / nested documents.
Major improvements in performance of the new Facet Module / JSON Facet API. See the facet performance benchmarks for more details and benchmark results.
The MoreLikeThis QParser mlt now supports all options provided by the MLT Handler. The query parser is much more versatile than the handler as it works in cloud mode as well as anywhere a normal query can be specified.
Example (on techproducts index):
q={!mlt qf=name mintf=1 mindf=1}SP2514N
More documentation on the mlt parser can be found in the Solr Ref Guide
Solr’s pseudo-join query parser has a new optional attribute score that can be used specify the scores produced on the resulting documents. It’s value can be min, max,avg,or total.
Smile is a binary data interchange format that is very close to Solr’s own “javabin” (encoded sizes are very close). Adding wt=smile to a request will cause the response to come back in this format.
In addition to many other improvements in the security framework, Solr now includes an AuthenticationPlugin implementing HTTP Basic Auth that stores credentials securely in ZooKeeper. This is a simple way to require a username and password for anyone accessing Solr’s admin screen or APIs.
Solr 5 has a completely re-written faceted search and analytics module with a structured JSON API to control the faceting and analytics commands. NOTE: Some examples use syntax only supported in later Solr 5 releases, or even Solr 6. Download a recent Solr release or snapshot to try them out.
The structured nature of nested sub-facets are more naturally expressed in a nested structure like JSON rather than the flat structure that normal query parameters provide.
Goals of the new Faceting Module:
First class JSON support
Easier programmatic construction of complex nested facet commands
Support a much more canonical response format that is easier for clients to parse
First class analytics support
Ability to sort facet buckets by any calculated metric
Support a cleaner way to do distributed faceting
Support better integration with other search features
Of course if you prefer to use Solr’s existing faceting capabilities, that’s fine too. You can even use both at once if you want!
UPDATE: The JSON Facet API is now part of the JSON Request API, so a complete request may be expressed in JSON.
Some of the ease-of-use enhancements over traditional Solr faceting come from the inherent nested structure of JSON. As an example, here is the faceting command for two different range facets using Solr’s flat legacy API:
&facet=true
&facet.range={!key=age_ranges}age
&f.age.facet.range.start=0
&f.age.facet.range.end=100
&f.age.facet.range.gap=10
&facet.range={!key=price_ranges}price
&f.price.facet.range.start=0
&f.price.facet.range.end=1000
&f.price.facet.range.gap=50
And here is the equivalent faceting command in the new JSON Faceting API:
{
age_ranges: {
type : range
field : age,
start : 0,
end : 100,
gap : 10
}
,
price_ranges: {
type : range
field : price,
start : 0,
end : 1000,
gap : 50
}
}
These aren’t even nested facets, but already one can see how much nicer the JSON API looks. With deeply nested sub-facets and statistics, the clarity of the inherently nested JSON API only grows.
A number of JSON extensions have been implemented to further increase the clarity and ease of constructing a JSON faceting command by hand. For example:
{ // this is a single-line comment, which can help add clarity to large JSON commands
/* traditional C-style comments are also supported */
x : "avg(price)" , // Simple strings can occur unquoted
y : 'unique(manu)'// Strings can also use single quotes (easier to embed in another String)
Nicely indented JSON is very easy to understand. If you get a large piece of non-indented JSON somehow, and are trying to make sense of it, you can cut and paste into one of the online validators: http://jsonlint.comhttp://jsonformatter.curiousconcept.com Both of these validators will indent your JSON, even when it contains extensions unsupported by them (such as comments or bare strings).
There are two types of facets, one that breaks up the domain into multiple buckets, and aggregations / facet functions that provide information about the set of documents belonging to each bucket.
Faceting can be nested! Any bucket produced by faceting can further be broken down into multiple buckets by a sub-facet.
Statistics are now fully integrated into faceting. Since we start off with a single facet bucket with a domain defined by the main query and filters, we can even ask for statistics for this top level bucket, before breaking up into further buckets via faceting. Example:
json.facet={
x : "avg(price)", // the average of the price field will appear under "x"
y : "unique(manufacturer)"// the number of unique manufacturers will appear under "y"
}
See facet functions for a complete list of the available aggregation functions.
The general form of the JSON facet commands are: <facet_name> : { <facet_type> : <facet_parameter(s)> } Example: top_authors : { terms : { field : authors, limit : 5 } }
After Solr 5.2, a flatter structure with a “type” field may also be used: <facet_name> : { "type" : <facet_type> , <other_facet_parameter(s)> } Example: top_authors : { type : terms, field : authors, limit : 5 }
The results will appear in the response under the facet name specified. Facet commands are specified using json.facet request parameters.
The terms facet, or field facet, produces buckets from the unique values of a field. The field needs to be indexed or have docValues.
The simplest form of the terms facet
{
top_genres : { terms : genre_field }
}
An expanded form allows for more parameters:
{
top_genres : {
type : terms,
field : genre_field,
limit : 3,
mincount : 2
}
}
Example response:
"top_genres":{
"buckets":[
{
"val":"Science Fiction",
"count":143},
{
"val":"Fantasy",
"count":122},
{
"val":"Biography",
"count":28}
]
}
Parameters:
field - The field name to facet over.
offset - Used for paging, this skips the first N buckets. Defaults to 0.
limit - Limits the number of buckets returned. Defaults to 10.
mincount - Only return buckets with a count of at least this number. Defaults to 1.
sort - Specifies how to sort the buckets produced. “count” specifies document count, “index” sorts by the index (natural) order of the bucket value. One can also sort by any facet function / statistic that occurs in the bucket. The default is “count desc”. This parameter may also be specified in JSON like sort:{count:desc}. The sort order may either be “asc” or “desc”
missing - A boolean that specifies if a special “missing” bucket should be returned that is defined by documents without a value in the field. Defaults to false.
numBuckets - A boolean. If true, adds “numBuckets” to the response, an integer representing the number of buckets for the facet (as opposed to the number of buckets returned). Defaults to false.
allBuckets - A boolean. If true, adds an “allBuckets” bucket to the response, representing the union of all of the buckets. For multi-valued fields, this is different than a bucket for all of the documents in the domain since a single document can belong to multiple buckets. Defaults to false.
prefix - Only produce buckets for terms starting with the specified prefix.
method - Provides an execution hint for how to facet the field.
method:uif - Stands for UninvertedField, a method of faceting indexed, multi-valued fields using top-level data structures that optimize for performance over NRT capabilities.
method:dv - Stands for DocValues, a method of faceting indexed, multi-valued fields using per-segment data structures. This method mirrors faceting on real docValues fields but works by building on-heap docValues on the fly from the index when docValues aren’t available. This method is better for a quickly changing index.
method:stream - This method creates each individual facet bucket (including any sub-facets) on-the-fly while streaming the response back to the requester. Currently only supports sorting by index order.
The range facet produces multiple range buckets over numeric fields or date fields.
Range facet example:
{
prices : {
type : range,
field : price,
start : 0,
end : 100,
gap : 20
}
}
Example response:
"prices":{
"buckets":[
{
"val":0.0, // the bucket value represents the start of each range. This bucket covers 0-20
"count":5},
{
"val":20.0,
"count":3},
{
"val":40.0,
"count":2},
{
"val":60.0,
"count":1},
{
"val":80.0,
"count":1}
]
}
To ease migration, these parameter names, values, and semantics were taken directly from the old-style (non JSON) Solr range faceting.
Parameters:
field - The numeric field or date field to produce range buckets from
mincount - Minimum document count for the bucket to be included in the response. Defaults to 0.
start - Lower bound of the ranges
end - Upper bound of the ranges
gap - Size of each range bucket produced
hardend - A boolean, which if true means that the last bucket will end at “end” even if it is less than “gap” wide. If false, the last bucket will be “gap” wide, which may extend past “end”.
other - This param indicates that in addition to the counts for each range constraint between facet.range.start and facet.range.end, counts should also be computed for…
"before" all records with field values lower then lower bound of the first range
"after" all records with field values greater then the upper bound of the last range
"between" all records with field values between the start and end bounds of all ranges
"none" compute none of this information
"all" shortcut for before, between, and after
include - By default, the ranges used to compute range faceting between facet.range.start and facet.range.end are inclusive of their lower bounds and exclusive of the upper bounds. The “before” range is exclusive and the “after” range is inclusive. This default, equivalent to lower below, will not result in double counting at the boundaries. This behavior can be modified by the facet.range.include param, which can be any combination of the following options…
"lower" all gap based ranges include their lower bound
"upper" all gap based ranges include their upper bound
"edge" the first and last gap ranges include their edge bounds (ie: lower for the first one, upper for the last one) even if the corresponding upper/lower option is not specified
"outer" the “before” and “after” ranges will be inclusive of their bounds, even if the first or last ranges already include those boundaries.