This is the place to define terms that are specific to Solr or that have meanings in the Solr community that differ from their meanings in the general populace.
When adding to this page, please list terms in alphabetical order.
Auto-warming: What Solr does when it opens a new cache, and seeds it with key/val pairs based on the "top" keys from the old instance of the cache
Constraint: A viable method of limiting a set of objects (*)
Core: See Solr Core below.
Facet: A distinct feature or aspect of a set of objects; "a way in which a resource can be classified" (*)
Filter: depending on context, may be:
- Another word for "Constraint"
- The "fq" param which constrains the results from a query without influencing the scores.
- Specifically referring to the Lucene "Filter" class
Request Handler: A Solr component that processes requests. For example, the DisMaxRequestHandler processes search queries by calling the DisMax Query Parser. Request Handlers can perform other functions, as well.
Query Parser: A Solr component that parses the parameters and search terms submitted in a search query.
Searcher: In Solr parlance, the term "Searcher" tends to refer to an instance of the SolrIndexSearcher class. This class is responsible for executing all searches done against the index, and manages several caches. There is typically one Searcher per SolrCore at any given time, and that searcher is used to execute all queries against that SolrCore, but there may be additional Searchers open at a time during cache warming (in which and "old Searcher" is still serving live requests while a "new Searcher" is being warmed up).
Shard: A distributed index is partitioned into "shards". Each shard corresponds to a Lucene instance and contains a disjoint subset of the documents in the index.
Slop: As in "phrase slop": the number of positions two tokens need to be moved in order to match a phrase in a query.
Solr Core: Also referred to as just a "Core" This is a running instance of a Solr index along with all of its configuration (SolrConfigXml, SchemaXml, etc...). A single Solr application can contain 0 or more cores which are run largely in isolation but can communicate with each other if necessary via the CoreContainer. From a historical perspective: Solr initially only supported one index, and the SolrCore class was a singleton for coordinating the low-level functionality at the "core" of Solr. When support was added for creating and managing multiple Cores on the fly, the class was refactored to no longer be a Singleton, but the name stuck.
Solr Home Dir: Also referred to as the "Solr Home Directory" or just "Solr Home" this is the main directory where Solr will look for configuration files, data, and plugins. Knowing which directory to use as the Solr Home is the one piece of information that Solr must either assume (the default is "./solr") or be configured using some mechanism beyond Solr's normal configuration files. An example Solr Home is included in Solr releases and contains a README.txt explaining the directory structure. For more information on ways to override the default Solr Home, please read SolrInstall.
Static warming: What users can do using newSearcher and firstSearcher event listeners to force explicit warming actions to be taken when one of these events happens -- frequently it involves seeding one or more caches with values from "static" queries hard coded in the solrconfig.xml