About This Guide
Fusion integrates Solr, the most widely deployed search engine in the planet, providing it with best in class open core search engine and data store.
Sole provides a modern, distributed, horizontally-scalable search-first NoSQL database optimized for information retrieval. By combining this capability with other key components such as pipelines, admin UI, security, Spark for data processing, etc., Fusion provides a massively scalable platform for applications driven by a combination of search, analytics and machine learning.
Fusion 4.2 integrates Solr 7.5.0. Key Solr features that are leveraged by Fusion include:
Faceting & Analytics
Sorting and Grouping
Complex Function Queries
Graph Queries and Traversals
Proven Scalability to trillions of records and internet-scale traffic (high read and write throughputs), and much more.
To facilitate development on Fusion 4, we have incorporated key portions of the Solr reference guide into our documentation. This provides you with an under the hood view of Fusion, and will help you use advanced Solr querying capabilities through the secure Fusion interface.
Solr is free to download from http://lucene.apache.org/solr/.
Designed to provide high-level documentation, this guide is intended to be more encyclopedic and less of a cookbook. It is structured to address a broad spectrum of needs, ranging from new developers getting started to well-experienced developers extending their application or troubleshooting. It will be of use at any point in the application life cycle, for whenever you need authoritative information about Solr.
The material as presented assumes that you are familiar with some basic search concepts and that you can read XML. It does not assume that you are a Java programmer, although knowledge of Java is helpful when working directly with Lucene or when developing custom extensions to a Lucene/Solr installation.
Hosts and Port Examples
The default port when running Solr is 8983. The samples, URLs and screenshots in this guide may show different ports, because the port number that Solr uses is configurable.
If you have not customized your installation of Solr, please make sure that you use port 8983 when following the examples, or configure your own installation to use the port numbers shown in the examples. For information about configuring port numbers, see the section Monitoring Solr.
Similarly, URL examples use
localhost throughout; if you are accessing Solr from a location remote to the server hosting Solr, replace
localhost with the proper domain or IP where Solr is running.
For example, we might provide a sample query like:
There are several items in this URL you might need to change locally. First, if your server is running at "www.example.com", you’ll replace "localhost" with the proper domain. If you aren’t using port 8983, you’ll replace that also. Finally, you’ll want to replace "gettingstarted" (the collection or core name) with the proper one in use in your implementation. The URL would then become:
Path information is given relative to
solr.home, which is the location under the main Solr installation where Solr’s collections and their
data directories are stored.
In many cases, this is is in the
server/solr directory of your installation. However, there can be exceptions, particularly if your installation has customized this.
In several cases of this Guide, our examples are built from the the "techproducts" example (i.e., you have started Solr with the command
bin/solr -e techproducts). In this case,
solr.home will be a sub-directory of the
example/ directory created for you automatically.
See also the section Solr Home for further details on what is contained in this directory.
Solr has two styles of APIs that currently co-exist. The first has grown somewhat organically as Solr has developed over time, but the second, referred to as the "V2 API", redesigns many of the original APIs with a modernized and self-documenting API interface.
In many cases, but not all, the parameters and outputs of API calls are the same between the two styles. In all cases the paths and endpoints used are different.
Throughout this Guide, we have added examples of both styles with sections labeled "V1 API" and "V2 API". As of the 7.2 version of this Guide, these examples are not yet complete - more coverage will be added as future versions of the Guide are released.
The section V2 API provides more information about how to work with the new API structure, including how to disable it if you choose to do so.
All APIs return a response header that includes the status of the request and the time to process it. Some APIs will also include the parameters used for the request. Many of the examples in this Guide omit this header information, which you can do locally by adding the parameter
omitHeader=true to any request.
Special Inline Notes
Special notes are included throughout these pages. There are several types of notes:
|Information blocks provide additional information that’s useful for you to know.|
|Important blocks provide information that we want to make sure you are aware of.|
|Tip blocks provide helpful tips.|
|Caution blocks provide details on scenarios or configurations you should be careful with.|
|Warning blocks are used to warn you from a possibly dangerous change or action.|