JSON Faceting exposes similar functionality to Solr’s traditional faceting but with a stronger emphasis on usability. It has several benefits over traditional faceting:

the nesting and structure offered by JSON makes facets easier to read and understand than the flat namespace of the traditional faceting API.

first class support for metrics and analytics

more standardized response format makes responses easier for clients to parse and use

final TermsFacetMap categoryFacet = new TermsFacetMap("cat").setLimit(3);
final JsonQueryRequest request =
    new JsonQueryRequest().setQuery("*:*").withFacet("categories", categoryFacet);
QueryResponse queryResponse = request.process(solrClient, COLLECTION_NAME);

Stat Facet Example

final TermsFacetMap categoryFacet = new TermsFacetMap("cat").setLimit(5);
final JsonQueryRequest request =
    new JsonQueryRequest().setQuery("*:*").withFacet("categories", categoryFacet);
QueryResponse queryResponse = request.process(solrClient, COLLECTION_NAME);

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”

overrequest

Number of buckets beyond the limit to internally request from shards during a distributed search.

Larger values can increase the accuracy of the final "Top Terms" returned when the individual shards have very diff top terms.

The default of -1 causes a heuristic to be applied based on the other options specified.

refine

If true , turns on distributed facet refining. This uses a second phase to retrieve any buckets needed for the final result from shards that did not include those buckets in their initial internal results, so that every shard contributes to every returned bucket in this facet and any sub-facets. This makes counts & stats for returned buckets exact.

overrefine

Number of buckets beyond the limit to consider internally during a distributed search when determining which buckets to refine.

Larger values can increase the accuracy of the final "Top Terms" returned when the individual shards have very diff top terms, and the current sort option can result in refinement pushing terms lower down the sorted list (ex: sort:"count asc" )

The default of -1 causes a heuristic to be applied based on other options specified.

mincount

Only return buckets with a count of at least this number. Defaults to 1 .

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 from 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.

facet

Aggregations, metrics or nested facets that will be calculated for every returned bucket

method

This parameter indicates the facet algorithm to use:

stream Presently equivalent to enum . Used for indexed, non-point fields with sort index asc and allBuckets , numBuckets , and missing disabled.

smart Pick the best method for the field type (this is the default)

QueryFacetMap queryFacet = new QueryFacetMap("popularity:[8 TO 10]");
final JsonQueryRequest request =
    new JsonQueryRequest().setQuery("*:*").withFacet("high_popularity", queryFacet);
QueryResponse queryResponse = request.process(solrClient, COLLECTION_NAME);

QueryFacetMap queryFacet =
    new QueryFacetMap("popularity:[8 TO 10]").withStatSubFacet("average_price", "avg(price)");
final JsonQueryRequest request =
    new JsonQueryRequest().setQuery("*:*").withFacet("high_popularity", queryFacet);
QueryResponse queryResponse = request.process(solrClient, COLLECTION_NAME);

RangeFacetMap rangeFacet = new RangeFacetMap("price", 0.0, 100.0, 20.0);
final JsonQueryRequest request =
    new JsonQueryRequest().setQuery("*:*").withFacet("prices", rangeFacet);
QueryResponse queryResponse = request.process(solrClient, COLLECTION_NAME);

Range Facet Parameters

Arbitrary Range

include with ranges

curl http://localhost:8983/solr/techproducts/query -d '
  "query": "*:*",
  "facet": {
    "prices": {
      "type": "range",
      "field": "price",
      "ranges": [
          "from": 0,
          "to": 20,
          "inclusive_from": true,
          "inclusive_to": false
          "range": "[40,100)"
The output from the range facet above would look a bit like:
  "prices": {
    "buckets": [
        "val": "[0,20)",
        "count": 5
        "val": "[40,100)",
        "count": 2
When range is specified, its value in the request is used as key in the response.
In the other case, key is generated using from, to, inclusive_to and inclusive_from.
Currently, custom key is not supported.
Heatmap Facet

The heatmap facet generates a 2D grid of facet counts for documents having spatial data in each grid cell.
This feature is primarily documented in the spatial section of the reference guide.
The key parameters are type to specify heatmap and field to indicate a spatial RPT field.
The rest of the parameter names use the same names and semantics mirroring
  facet.heatmap query-parameter style faceting, albeit without the "facet.heatmap." prefix.
For example geom here corresponds to facet.heatmap.geom in a facet.heatmap command.
            "locations",
            new HeatmapFacetMap("location_srpt")
                .setHeatmapFormat(HeatmapFacetMap.HeatmapFormat.INTS2D)
                .setRegionQuery("[\"50 20\" TO \"180 90\"]")
                .setGridLevel(4));

Stat Facet Functions

same as above with smaller footprint strictly for counting the number of Block Join blocks . The given field must be unique across blocks, and only singlevalued string fields are supported, docValues are recommended.

uniqueBlock({!v=type:parent}) or uniqueBlock({!v=$qryref}) where qryref=type:parent

same as above, but using bitset of the given query to aggregate hits.

hll(author)

distributed cardinality estimate via hyper-log-log algorithm

percentile

percentile(salary,50,75,99,99.9)

Percentile estimates via t-digest algorithm. When sorting by this metric, the first percentile listed is used as the sort value.

sumsq

sumsq(rent)

sum of squares of field or function

variance

variance(rent)

variance of numeric field or function

stddev

stddev(rent)

standard deviation of field or function

relatedness

relatedness('popularity:[100 TO *]','inStock:true')

A function for computing a relatedness score of the documents in the domain to a Foreground set, relative to a Background set (both defined as queries). This is primarily for use when building Semantic Knowledge Graphs .

Numeric aggregation functions such as avg can be on any numeric field, or on a nested function of multiple numeric fields such as avg(div(popularity,price)) .

The most common way of requesting an aggregation function is as a simple String containing the expression you wish to compute:

final Map<String, Object> expandedStatFacet = new HashMap<>();
expandedStatFacet.put("type", "func");
expandedStatFacet.put("func", "avg(div($numer,$denom))");
expandedStatFacet.put("numer", "mul(popularity,3.0)");
expandedStatFacet.put("denom", "price");
final JsonQueryRequest request =
    new JsonQueryRequest()
        .setQuery("*:*")
        .withFilter("price:[1.0 TO *]")
        .withFilter("popularity:[0 TO 10]")
        .withFacet("avg_value", expandedStatFacet);
QueryResponse queryResponse = request.process(solrClient, COLLECTION_NAME);

Nested facets, or sub-facets , allow one to nest facet commands under any facet command that partitions the domain into buckets (i.e., terms , range , query ). These sub-facets are then evaluated against the domains defined by the set of all documents in each bucket of their parent.

The syntax is identical to top-level facets - just add a facet command to the facet command block of the parent facet. Technically, every facet command is actually a sub-facet since we start off with a single facet bucket with a domain defined by the main query and filters.

Nested Facet Example

final TermsFacetMap categoryFacet = new TermsFacetMap("cat").setLimit(3);
final JsonQueryRequest request =
    new JsonQueryRequest().setQuery("*:*").withFacet("categories", categoryFacet);
QueryResponse queryResponse = request.process(solrClient, COLLECTION_NAME);

final TermsFacetMap topCategoriesFacet = new TermsFacetMap("cat").setLimit(3);
final TermsFacetMap topManufacturerFacet = new TermsFacetMap("manu_id_s").setLimit(1);
topCategoriesFacet.withSubFacet("top_manufacturers", topManufacturerFacet);
final JsonQueryRequest request =
    new JsonQueryRequest().setQuery("*:*").withFacet("categories", topCategoriesFacet);
QueryResponse queryResponse = request.process(solrClient, COLLECTION_NAME);

Sorting Facets By Nested Functions

In addition to this default behavior, domains can be also be widened, narrowed, or changed entirely. The JSON Faceting API supports modifying domains through its domain property. This is discussed in more detail in JSON Faceting Domain Changes .

Most stat facet functions ( avg , sumsq , etc.) allow users to perform math computations on groups of documents. A few functions are more involved though, and deserve an explanation of their own. These are described in more detail in the sections below.

uniqueBlock() and Block Join Counts

When a collection contains nested documents , the blockChildren and blockParent domain changes can be useful when searching for parent documents and you want to compute stats against all of the affected children documents (or vice versa). But if you only need to know the count of all the blocks that exist in the current domain, a more efficient option is the uniqueBlock() aggregate function.

Suppose we have products with multiple SKUs, and we want to count products for each color.

When searching against a set of SKU documents, we can ask for a facet on color, with a nested statistic counting all the "blocks" — aka: products:

"color": {
  "type": "terms",
  "field": "color",
  "limit": -1,
  "facet": {
    "productsCount": "uniqueBlock(_root_)"
      // or "uniqueBlock({!v=type:product})"
and get:
"color": {
   "buckets": [
      { "val": "Blue", "count": 2, "productsCount": 2 },
      { "val": "Red", "count": 2, "productsCount": 1 }
Please notice that _root_ is an internal field added by Lucene to each child document to reference on parent one.
Aggregation uniqueBlock(_root_) is functionally equivalent to unique(_root_), but is optimized for nested documents block structure.
It’s recommended to define limit: -1 for uniqueBlock calculation, like in above example,
since default value of limit parameter is 10, while uniqueBlock is supposed to be much faster with -1.
relatedness() and Semantic Knowledge Graphs

The relatedness(…​) stat function allows for sets of documents to be scored relative to Foreground and Background sets of documents, for the purposes of finding ad-hoc relationships that make up a "Semantic Knowledge Graph":
At its heart, the Semantic Knowledge Graph leverages an inverted index, along with a complementary uninverted index, to represent nodes (terms) and edges (the documents within intersecting postings lists for multiple terms/nodes).
This provides a layer of indirection between each pair of nodes and their corresponding edge, enabling edges to materialize dynamically from underlying corpus statistics.
As a result, any combination of nodes can have edges to any other nodes materialize and be scored to reveal latent relationships between the nodes.
— Grainger et al.

The Semantic Knowledge Graph
The relatedness(…​) function is used to "score" these relationships, relative to "Foreground" and "Background" sets of documents, specified in the function params as queries.
Unlike most aggregation functions, the relatedness(…​) function is aware of whether and how it’s used in Nested Facets.  It evaluates the query defining the current bucket independently of its parent/ancestor buckets, and intersects those documents with a "Foreground Set" defined by the foreground query combined with the ancestor buckets.  The result is then compared to a similar intersection done against the "Background Set" (defined exclusively by background query) to see if there is a positive, or negative, correlation between the current bucket and the Foreground Set, relative to the Background Set.
While it’s very common to define the Background Set as *:*, or some other super-set of the Foreground Query, it is not strictly required.
The relatedness(…​) function can be used to compare the statistical relatedness of sets of documents to orthogonal foreground/background queries.
relatedness() Options

When using the extended type:func syntax for specifying a relatedness() aggregation, an optional min_popularity (float) option can be used to specify a lower bound on the foreground_popularity and background_popularity values, that must be met in order for the relatedness score to be valid — If this min_popularity is not met, then the relatedness score will be -Infinity.
The default implementation for calculating relatedness() domain correlation depends on the type of facet being calculated.
Generic domain correlation is calculated per-term, by selectively retrieving a DocSet for each bucket-associated query (consulting the filterCache) and calculating DocSet intersections with "foreground" and "background" sets.
For term facets (especially over high-cardinality fields) this approach can lead to filterCache thrashing; accordingly, relatedness() over term facets defaults where possible to an approach that collects facet counts directly over all multiple domains in a single sweep (never touching the filterCache).
It is possible to explicitly control this "single sweep" collection by setting the extended type:func syntax sweep_collection option to true (the default) or false (to disable sweep collection).
Disabling sweep collection for relatedness() stats over low-cardinality fields may yield a performance benefit, provided the filterCache is sufficiently large to accommodate an entry for each value in the associated field without inducing thrashing for anticipated use patterns.
A reasonable heuristic is that fields of cardinality less than 1,000 may benefit from disabling sweep.
This heuristic is not used to determine default behavior, particularly because non-sweep collection can so easily induce filterCache thrashing, with system-wide detrimental effects.
When sorting on relatedness(…​) requests can be processed much more quickly by adding a prelim_sort: "count desc" option.
Increasing the overrequest can help improve the accuracy of the top buckets.
Sample Documents
curl -sS -X POST 'http://localhost:8983/solr/gettingstarted/update?commit=true' -d '[
{"id":"01",age:15,"state":"AZ","hobbies":["soccer","painting","cycling"]},
{"id":"02",age:22,"state":"AZ","hobbies":["swimming","darts","cycling"]},
{"id":"03",age:27,"state":"AZ","hobbies":["swimming","frisbee","painting"]},
{"id":"04",age:33,"state":"AZ","hobbies":["darts"]},
{"id":"05",age:42,"state":"AZ","hobbies":["swimming","golf","painting"]},
{"id":"06",age:54,"state":"AZ","hobbies":["swimming","golf"]},
{"id":"07",age:67,"state":"AZ","hobbies":["golf","painting"]},
{"id":"08",age:71,"state":"AZ","hobbies":["painting"]},
{"id":"09",age:14,"state":"CO","hobbies":["soccer","frisbee","skiing","swimming","skating"]},
{"id":"10",age:23,"state":"CO","hobbies":["skiing","darts","cycling","swimming"]},
{"id":"11",age:26,"state":"CO","hobbies":["skiing","golf"]},
{"id":"12",age:35,"state":"CO","hobbies":["golf","frisbee","painting","skiing"]},
{"id":"13",age:47,"state":"CO","hobbies":["skiing","darts","painting","skating"]},
{"id":"14",age:51,"state":"CO","hobbies":["skiing","golf"]},
{"id":"15",age:64,"state":"CO","hobbies":["skating","cycling"]},
{"id":"16",age:73,"state":"CO","hobbies":["painting"]},
Example Query
curl -sS -X POST http://localhost:8983/solr/gettingstarted/query -d 'rows=0&q=*:*
&back=*:*                                  (1)
&fore=age:[35 TO *]                        (2)
&json.facet={
  hobby : {
    type : terms,
    field : hobbies,
    limit : 5,
    sort : { r1: desc },                   (3)
    facet : {
      r1 : "relatedness($fore,$back)",     (4)
      location : {
        type : terms,
        field : state,
        limit : 2,
        sort : { r2: desc },               (3)
        facet : {
          r2 : "relatedness($fore,$back)"  (4)
For both the top level hobbies facet & the sub-facet on state we will be sorting on the relatedness(…​) values
In both calls to the relatedness(…​) function, we use parameter variables to refer to the previously defined fore and back queries.
          "relatedness":0.01225,
          "foreground_popularity":0.3125,         (2)
          "background_popularity":0.375},         (3)
        "location":{
          "buckets":[{
              "val":"az",
              "count":3,
              "r2":{
                "relatedness":0.00496,            (4)
                "foreground_popularity":0.1875,   (6)
                "background_popularity":0.5}},    (7)
              "val":"co",
              "count":3,
              "r2":{
                "relatedness":-0.00496,           (5)
                "foreground_popularity":0.125,
                "background_popularity":0.5}}]}},
        "val":"painting",
        "count":8,                                (1)
        "r1":{
          "relatedness":0.01097,
          "foreground_popularity":0.375,
          "background_popularity":0.5},
        "location":{
          "buckets":[{
Even though hobbies:golf has a lower total facet count then hobbies:painting, it has a higher relatedness score, indicating that relative to the Background Set (the entire collection) Golf has a stronger correlation to our Foreground Set (people age 35+) then Painting.
The number of documents matching age:[35 TO *] and hobbies:golf is 31.25% of the total number of documents in the Background Set
37.5% of the documents in the Background Set match hobbies:golf
The state of Arizona (AZ) has a positive relatedness correlation with the nested Foreground Set (people ages 35+ who play Golf) compared to the Background Set — i.e., "People in Arizona are statistically more likely to be '35+ year old Golfers' than the country as a whole."
The state of Colorado (CO) has a negative correlation with the nested Foreground Set — i.e., "People in Colorado are statistically less likely to be '35+ year old Golfers' then the country as a whole."
The number documents matching age:[35 TO *] and hobbies:golf and state:AZ is 18.75% of the total number of documents in the Background Set
50% of the documents in the Background Set match state:AZ