Apache Solr Reference Guide Covering Apache Solr 6.0

worker nodes. It involves sorting and partitioning the entire result set and sending it to worker nodes. In
this approach the tuples arrive at the worker nodes sorted by the GROUP BY fields. The worker nodes
can then rollup the aggregates one group at a time. This allows for unlimited cardinality aggregation, but
you pay the price of sending the entire result set across the network to worker nodes.
facet: This uses the JSON Facet API or StatsComponent for aggregations. In this scenario the
aggregations logic is pushed down into the search engine and only the aggregates are sent across the
network. This is Solr's normal mode of operation. This is fast when the cardinality of GROUP BY fields is
low to moderate. But it breaks down when you have high cardinality fields in the GROUP BY field.
These modes are defined with the aggregationMode property when sending the request to Solr.
As noted, the choice between aggregation modes depends on the cardinality of the fields you are working with. If
you have low-to-moderate cardinality in the fields you are grouping by, the 'facet' aggregation mode will give you
a higher performance because only the final groups are returned, very similar to how facets work today. If,
however, you have high cardinality in the fields, the "map_reduce" aggregation mode with worker nodes provide
a much more performant option.
More detail on the architecture of the "map_reduce" query is in the section Parallel Query Architecture.
Configuration
The request handlers used for the SQL interface are configured to load implicitly, meaning there is little to do to
start using this feature.
/sql Request Handler
The /sql handler is the front end of the Parallel SQL interface. All SQL queries are sent to the /sql handler to
be processed. The handler also coordinates the distributed MapReduce jobs when running GROUP BY and SELE
CT DISTINCT queries in map_reduce mode. By default the /sql handler will choose worker nodes from it's
own collection to handle the distributed operations. In this default scenario the collection where the /sql handler
resides acts as the default worker collection for MapReduce queries.
By default, the /sql request handler is configured as an implicit handler, meaning that it is always enabled in
every Solr installation and no further configuration is required.
As described below in the section Best Practices, you may want to set up a separate collection for
parallelized SQL queries. If you have high cardinality fields and a large amount of data, please be sure to
review that section and
/stream and /export Request Handlers
The Streaming API is an extensible parallel computing framework for SolrCloud. Streaming Expressions provide
a query language and a serialization format for the Streaming API. The Streaming API provides support for fast
MapReduce allowing it to perform parallel relational algebra on extremely large data sets. Under the covers the
SQL interface parses SQL queries using the Presto SQL Parser. It then translates the queries to the parallel
query plan. The parallel query plan is expressed using the Streaming API and Streaming Expressions.
Like the /sql request handler, the /stream and /export request handlers are configured as implicit handlers,
and no further configuration is required.
Fields
In some cases, fields used in SQL queries must be configured as DocValue fields. If queries are unlimited, all
fields must be DocValue fields. If queries are limited (with the limit clause) then fields do not have to be have
Apache Solr Reference Guide 6.0
427