Solr
Solr¶
Apache Solr is a scalable and fault-tolerant search index.
Solr search with generic schemas provided, and a custom schema is also supported.
To use it in your application, add it to .symfony/services.yaml:
1 2 3 4 | mysearch:
# supported versions: 3.6, 4.10, 6.3, 6.6, 7.6, 7.7, 8.0, 8.4
type: solr:8.4
disk: 1024
|
And wire it in .symfony.cloud.yaml:
1 2 | relationships:
solr: "mysearch:solr"
|
Environment Variables¶
The configuration is exposed via the following environment variables (where
SOLR is the upper-cased version of the key defined in the relationship
above):
SOLR_HOST: The Solr hostSOLR_PORT: The Solr portSOLR_NAME: The Solr nameSOLR_DATABASE: An alias forSOLR_NAME
Configuration¶
Solr 4¶
For Solr 4, SymfonyCloud supports only a single core per server called
collection1.
If you want to provide your own Solr configuration, add a core_config key in
the .symfony/services.yaml file:
1 2 3 4 5 | mysearch:
type: solr:4.10
disk: 1024
configuration:
core_config: !archive "<directory>"
|
The directory parameter points to a directory in the Git repository, in or
below the .symfony/ folder. This directory needs to contain everything that
Solr needs to start a core. At the minimum, solrconfig.xml and schema.xml.
Solr 6 and later¶
For Solr 6 and later, SymfonyCloud supports multiple cores via different endpoints. Cores and endpoints are defined separately, with endpoints referencing cores. Each core may have its own configuration or share a configuration:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | solrsearch:
type: solr:6.6
disk: 1024
configuration:
cores:
mainindex:
conf_dir: !archive "core1-conf"
extraindex:
conf_dir: !archive "core2-conf"
endpoints:
main:
core: mainindex
extra:
core: extraindex
|
Each endpoint is available in the relationships definition in
.symfony.cloud.yaml:
1 2 3 | relationships:
solr1: 'solrsearch:main'
solr2: 'solrsearch:extra'
|
Configsets¶
For even more customizability, it’s also possible to define Solr configsets. For
example, the following snippet would define one configset, which would be used
by all cores. Specific details can then be overridden by individual cores using
core_properties, which is equivalent to the Solr core.properties file.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | solrsearch:
type: solr:8.4
disk: 1024
configuration:
configsets:
mainconfig: !archive "configsets/solr6"
cores:
english_index:
core_properties: |
configSet=mainconfig
schema=english/schema.xml
arabic_index:
core_properties: |
configSet=mainconfig
schema=arabic/schema.xml
endpoints:
english:
core: english_index
arabic:
core: arabic_index
|
Caution
Note that not all core.properties features make sense to specify in the
core_properties property. Some keys, such as name and dataDir,
are not supported, and may result in a solrconfig that fails to work as
intended, or at all.
Default configuration¶
If no configuration is specified, the default configuration is equivalent to:
1 2 3 4 5 6 7 8 9 | solrsearch:
type: solr:8.4
configuration:
cores:
collection1:
conf_dir: {} # This will pick up the default configuration
endpoints:
solr:
core: collection1
|
Limitations¶
The recommended maximum size for configuration directories (zipped) is 2MB. These need to be monitored to ensure they don’t grow beyond that. If the zipped configuration directories grow beyond this, performance will decline and deploys will become longer. The directory archives will be compressed and string encoded. You could use this bash pipeline inside the directory to get an idea of the archive size:
1 | $ echo $(($(tar czf - . | base64 | wc -c )/(1024*1024))) Megabytes
|
The !archive "<directory"> is a collection of configuration data, like a
data dictionary, e.g. small collections of key/ value sets. The best way to
keep the size small is to restrict the directory context to plain
configurations. Including binary data like plugin .jars will inflate the
archive size, and is not recommended.
This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.