mirror of https://github.com/apache/lucene.git
Ref Guide: prep for 8.6: upgrade notes, typos
This commit is contained in:
Cassandra Targett
parent
aad8c983e5
commit
f1650d5f47
|
|
@ -141,7 +141,7 @@ Step 2: Get the `sha512` hash of the jar
|
|||
openssl dgst -sha512 runtimelibs.jar
|
||||
----
|
||||
|
||||
Step 3 : Start Solr with runtime lib enabled
|
||||
Step 3: Start Solr with runtime lib enabled
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -215,7 +215,7 @@ Support for the "collectionDefaults" key will be removed in Solr 9.
|
|||
|
||||
=== Default Shard Preferences
|
||||
|
||||
Using the `defaultShardPreferences` parameter, you can implement rack or availability zone awareness. First, make sure to "label" your nodes using a <<configuring-solrconfig-xml.adoc#jvm-system-properties,system property>> (e.g. `-Drack=rack1`). Then, set the value of `defaultShardPreferences` to `node.sysprop:sysprop.YOUR_PROPERTY_NAME` like this:
|
||||
Using the `defaultShardPreferences` parameter, you can implement rack or availability zone awareness. First, make sure to "label" your nodes using a <<configuring-solrconfig-xml.adoc#jvm-system-properties,system property>> (e.g., `-Drack=rack1`). Then, set the value of `defaultShardPreferences` to `node.sysprop:sysprop.YOUR_PROPERTY_NAME` like this:
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
|
|
@ -228,7 +228,7 @@ curl -X POST -H 'Content-type:application/json' --data-binary '
|
|||
}' http://localhost:8983/api/cluster
|
||||
----
|
||||
|
||||
At this point, if you run a query on a node having e.g. `rack=rack1`, Solr will try to hit only replicas from `rack1`.
|
||||
At this point, if you run a query on a node having e.g., `rack=rack1`, Solr will try to hit only replicas from `rack1`.
|
||||
|
||||
[[balanceshardunique]]
|
||||
== BALANCESHARDUNIQUE: Balance a Property Across Nodes
|
||||
|
|
@ -498,4 +498,4 @@ http://localhost:8983/solr/admin/collections?action=OVERSEERSTATUS
|
|||
],
|
||||
"..."
|
||||
}
|
||||
----
|
||||
----
|
||||
|
|
|
|||
|
|
@ -146,16 +146,19 @@ q=foo&fq={!collapse field=ISBN}&expand=true
|
|||
|
||||
[IMPORTANT]
|
||||
====
|
||||
When used with CollapsingQParserPlugin and there are multiple collapse groups then, the field is chosen from group with least cost.
|
||||
If there are multiple collapse groups with same cost then, the first specified one is chosen
|
||||
When used with CollapsingQParserPlugin and there are multiple collapse groups, the field is chosen from the group with least cost.
|
||||
If there are multiple collapse groups with same cost then the first specified one is chosen.
|
||||
====
|
||||
|
||||
The “expand=true” parameter turns on the ExpandComponent. The ExpandComponent adds a new section to the search output labeled “expanded”.
|
||||
When enabled, the ExpandComponent adds a new section to the search output labeled `expanded`.
|
||||
|
||||
Inside the expanded section there is a _map_ with each group head pointing to the expanded documents that are within the group. As applications iterate the main collapsed result set, they can access the _expanded_ map to retrieve the expanded groups.
|
||||
Inside the `expanded` section there is a _map_ with each group head pointing to the expanded documents that are within the group. As applications iterate the main collapsed result set, they can access the _expanded_ map to retrieve the expanded groups.
|
||||
|
||||
The ExpandComponent has the following parameters:
|
||||
|
||||
`expand`::
|
||||
When `true`, the ExpandComponent is enabled.
|
||||
|
||||
`expand.field`::
|
||||
Field on which expand documents need to be populated. When `expand=true`, either this parameter needs to be specified or should be used with CollapsingQParserPlugin.
|
||||
When both are specified, this parameter is given higher priority.
|
||||
|
|
@ -165,10 +168,10 @@ Orders the documents within the expanded groups. The default is `score desc`.
|
|||
|
||||
`expand.rows`::
|
||||
The number of rows to display in each group. The default is 5 rows.
|
||||
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
When `expand.rows=0`, then only the number of documents found for each expanded value is returned. Hence, scores won't be computed even if requested. `maxScore` is set to 0
|
||||
When `expand.rows=0`, only the number of documents found for each expanded value is returned. Hence, scores won't be computed even if requested and `maxScore` is set to 0.
|
||||
====
|
||||
|
||||
`expand.q`::
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ Regarding the sort parameter's arguments:
|
|||
** When more than one sort criteria is provided, the second entry will only be used if the first entry results in a tie. If there is a third entry, it will only be used if the first AND second entries are tied. And so on.
|
||||
** If documents tie in all of the explicit sort criteria, Solr uses each document's Lucene document ID as the final tie-breaker.
|
||||
This internal property is subject to change during segment merges and document updates, which can lead to unexpected result ordering changes.
|
||||
Users looking to avoid this behavior can add an additional sort criteria on a unique or rarely-shared field such as `id` to prevent ties from occurring (e.g. `price desc,id asc`).
|
||||
Users looking to avoid this behavior can add an additional sort criteria on a unique or rarely-shared field such as `id` to prevent ties from occurring (e.g., `price desc,id asc`).
|
||||
|
||||
== start Parameter
|
||||
|
||||
|
|
@ -382,8 +382,8 @@ q=quick brown fox&minExactCount=100&rows=10
|
|||
"numFound": 153,
|
||||
"start": 0,
|
||||
"numFoundExact": false,
|
||||
"docs": Array[10]
|
||||
...
|
||||
"docs": [{"doc1"}]
|
||||
}
|
||||
----
|
||||
Since `numFoundExact=false`, we know the number of documents matching the query is greater or equal to 153. If we specify a higher value for `minExactCount`:
|
||||
|
||||
|
|
@ -396,7 +396,7 @@ q=quick brown fox&minExactCount=200&rows=10
|
|||
"numFound": 163,
|
||||
"start": 0,
|
||||
"numFoundExact": true,
|
||||
"docs": Array[10]
|
||||
...
|
||||
"docs": [{"doc1"}]
|
||||
}
|
||||
----
|
||||
In this case we know that `163` is the exact number of hits for the query. Both queries must have returned the same number of documents in the top 10.
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ In SolrCloud mode this whitelist is automatically configured to include all live
|
|||
+
|
||||
In standalone mode the whitelist defaults to empty (sharding not allowed).
|
||||
+
|
||||
If you need to disable this feature for backwards compatibility, you can set the system property `solr.disable.shardsWhitelist=true`. The value of this parameter is a comma separated list of the nodes that will be whitelisted, i.e.:
|
||||
If you need to disable this feature for backwards compatibility, you can set the system property `solr.disable.shardsWhitelist=true`. The value of this parameter is a comma separated list of the nodes that will be whitelisted, i.e.,
|
||||
`10.0.0.1:8983/solr,10.0.0.1:8984/solr`.
|
||||
+
|
||||
NOTE: In SolrCloud mode, if at least one node is included in the whitelist, then the `live_nodes` will no longer be used as source for the list. This means that if you need to do a cross-cluster request using the `shards` parameter in SolrCloud mode (in addition to regular within-cluster requests), you'll need to add all nodes (local cluster + remote nodes) to the whitelist.
|
||||
|
|
@ -190,7 +190,7 @@ Applied after sorting by inherent replica attributes, this property defines a fa
|
|||
`stable[:hash[:_paramName_]]` the string value associated with the given parameter name is hashed to a dividend that is used to determine replica preference order (analogous to the explicit `dividend` property above); `_paramName_` defaults to `q` if not specified, providing stable routing keyed to the string value of the "main query". Note that this may be inappropriate for some use cases (e.g., static main queries that leverage parameter substitution)
|
||||
|
||||
`node.sysprop`::
|
||||
Query will be routed to nodes with same defined system properties as the current one. For example, if you start Solr nodes on different racks, you'll want to identify those nodes by a <<configuring-solrconfig-xml.adoc#jvm-system-properties,system property>> (e.g. `-Drack=rack1`). Then, queries can contain `shards.preference=node.sysprop:sysprop.rack`, to make sure you always hit shards with the same value of `rack`.
|
||||
Query will be routed to nodes with same defined system properties as the current one. For example, if you start Solr nodes on different racks, you'll want to identify those nodes by a <<configuring-solrconfig-xml.adoc#jvm-system-properties,system property>> (e.g., `-Drack=rack1`). Then, queries can contain `shards.preference=node.sysprop:sysprop.rack`, to make sure you always hit shards with the same value of `rack`.
|
||||
|
||||
|
||||
Examples:
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ Currently non-operational.
|
|||
Specifies the path to a common library directory that will be shared across all cores. Any JAR files in this directory will be added to the search path for Solr plugins. If the specified path is not absolute, it will be relative to `$SOLR_HOME`. Custom handlers may be placed in this directory. Note that specifying `sharedLib` will not remove `$SOLR_HOME/lib` from Solr's class path.
|
||||
|
||||
`allowPaths`::
|
||||
Solr will normally only access folders relative to `$SOLR_HOME`, `$SOLR_DATA_HOME` or `coreRootDir`. If you need to e.g. create a core outside of these paths, you can explicitly allow the path with `allowPaths`. It is a comma separated string of file system paths to allow. The special value of `*` will allow any path on the system.
|
||||
Solr will normally only access folders relative to `$SOLR_HOME`, `$SOLR_DATA_HOME` or `coreRootDir`. If you need to e.g., create a core outside of these paths, you can explicitly allow the path with `allowPaths`. It is a comma separated string of file system paths to allow. The special value of `*` will allow any path on the system.
|
||||
|
||||
`shareSchema`::
|
||||
This attribute, when set to `true`, ensures that the multiple cores pointing to the same Schema resource file will be referring to the same IndexSchema Object. Sharing the IndexSchema Object makes loading the core faster. If you use this feature, make sure that no core-specific property is used in your Schema file.
|
||||
|
|
|
|||
|
|
@ -37,6 +37,20 @@ File:: Returns content of files in `${solr.home}/conf/`. This handler must have
|
|||
|`solr/<collection>/admin/file` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/ShowFileRequestHandler.html[ShowFileRequestHandler] |`_ADMIN_FILE`
|
||||
|===
|
||||
|
||||
Health:: Reporting the health of the node (_available only in SolrCloud mode_)
|
||||
+
|
||||
[cols="3*.",frame=none,grid=cols,options="header"]
|
||||
|===
|
||||
|API Endpoints |Class & Javadocs |Paramset
|
||||
|v1: `solr/admin/info/health`
|
||||
|
||||
v2: `api/node/health` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/HealthCheckHandler.html[HealthCheckHandler] |`_ADMIN_HEALTH`
|
||||
|===
|
||||
+
|
||||
This endpoint can also take the collection or core name in the path (`solr/<collection>/admin/health` or `solr/<core>/admin/health`).
|
||||
+
|
||||
This endpoint also accepts additional request parameters. Please see {solr-javadocs}/solr-core/org/apache/solr/handler/admin/HealthCheckHandler.html[Javadocs] for details.
|
||||
|
||||
Logging:: Retrieve and modify registered loggers.
|
||||
+
|
||||
[cols="3*.",frame=none,grid=cols,options="header"]
|
||||
|
|
@ -126,20 +140,6 @@ Threads:: Return info on all JVM threads.
|
|||
v2: `api/node/threads` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/ThreadDumpHandler.html[ThreadDumpHandler] |`_ADMIN_THREADS`
|
||||
|===
|
||||
|
||||
Health:: Reporting the health of the node (_available only in SolrCloud mode_)
|
||||
+
|
||||
[cols="3*.",frame=none,grid=cols,options="header"]
|
||||
|===
|
||||
|API Endpoints |Class & Javadocs |Paramset
|
||||
|v1: `solr/admin/info/health`
|
||||
|
||||
v2: `api/node/health` |{solr-javadocs}/solr-core/org/apache/solr/handler/admin/HealthCheckHandler.html[HealthCheckHandler] |`_ADMIN_HEALTH`
|
||||
|===
|
||||
|
||||
This endpoint can also take the collection or core name in the path (`solr/<collection>/admin/health` or `solr/<core>/admin/health`).
|
||||
|
||||
This endpoint also accepts additional request parameters. Please see {solr-javadocs}/solr-core/org/apache/solr/handler/admin/HealthCheckHandler.html[Javadocs] for details.
|
||||
|
||||
=== Analysis Handlers
|
||||
|
||||
[horizontal]
|
||||
|
|
|
|||
|
|
@ -341,7 +341,13 @@ include::{example-source-dir}JsonRequestApiTest.java[tag=solrj-ipod-query-bool-f
|
|||
|
||||
== Additional Queries
|
||||
|
||||
Multiple additional queries might be specified under `queries` key with all syntax alternatives described above. Every entry might have multiple values in array. To reference these queries one can use `{"param":"query_name"}`, as well as old-style referencing `"{!v=$query_name}"`. Beware of arity for these references. Depending on the context, a reference might be resolved into the first element in array ignoring the later elements, e.g., if one changes the reference below from `{"param":"electronic"}` to `{"param":"manufacturers"}` it's equivalent to querying for `manu:apple`, ignoring the later query. These queries don't impact query result until explicit referencing.
|
||||
Multiple additional queries might be specified under `queries` key with all syntax alternatives described above.
|
||||
Every entry might have multiple values in an array.
|
||||
To reference these queries one can use `{"param":"query_name"}`, as well as old-style referencing `"{!v=$query_name}"`.
|
||||
Beware of arity for these references.
|
||||
|
||||
Depending on the context, a reference might be resolved into the first element in array ignoring the later elements, e.g., if one changes the reference below from `{"param":"electronic"}` to `{"param":"manufacturers"}` it's equivalent to querying for `manu:apple`, ignoring the later query.
|
||||
These queries don't impact query result until explicit referencing.
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
|
|
@ -358,7 +364,7 @@ curl -X POST http://localhost:8983/solr/techproducts/query -d '
|
|||
}'
|
||||
----
|
||||
|
||||
Overall this example doesn't make much sense, but just demonstrates the syntax. This feature is useful in <<json-faceting-domain-changes.adoc#adding-domain-filters,filtering domain>> in JSON Facet API <<json-facet-api.adoc#changing-the-domain,domain changes>>. Note that these declarations add request parameters underneath, so using same names with other parameters might cause unexpected behavior.
|
||||
Overall this example doesn't make much sense, but just demonstrates the syntax. This feature is useful in <<json-faceting-domain-changes.adoc#adding-domain-filters,filtering domain>> in JSON Facet API <<json-facet-api.adoc#changing-the-domain,domain changes>>. Note that these declarations add request parameters underneath, so using same names with other parameters might cause unexpected behavior.
|
||||
|
||||
== Tagging in JSON Query DSL
|
||||
Query and filter clauses can also be individually "tagged". Tags serve as handles for query clauses, allowing them to be referenced from elsewhere in the request. This is most commonly used by the filter-exclusion functionality offered by both <<faceting.adoc#tagging-and-excluding-filters,traditional>> and <<json-faceting-domain-changes.adoc#filter-exclusions,JSON>> faceting.
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ There are several points to keep in mind:
|
|||
* The G1GC garbage collector is currently preferred when using a JVM that supports it (Java 9 and later).
|
||||
* Modern hardware can be configured with hundreds of gigabytes of physical RAM and many CPUs. It is often better in these cases to run multiple JVMs, each with a limited amount of memory allocated to their heaps. One way to achieve this is to run Solr as a https://hub.docker.com/_/solr?tab=tags[Docker container].
|
||||
* It's good practice to periodically re-analyze the GC logs and/or monitor with <<metrics-reporting#metrics-reporting,Metrics Reporting>> to see if the memory usage has changed due to changes in your application, number of documents, etc.
|
||||
* On *nix systems, we recommend that Solr be run with the "OOM killer script" (see `solr/bin/oom_solr.sh`). This will forcefully stop Solr when the heap is exhausted rather than continue in an indeterminate state.
|
||||
* On *nix systems, we recommend that Solr be run with the "OOM killer script" (see `solr/bin/oom_solr.sh`). This will forcefully stop Solr when the heap is exhausted rather than continue in an indeterminate state. If `jstack` is available, a heap dump will also be taken before the process is killed.
|
||||
* All current (Java 11) garbage collectors can hit "stop the world" collections, which suspend the JVM until completed. If, through monitoring, these garbage collections are frequent and greater than your application can tolerate, additional tuning should be considered. "Stop the world" pauses greater than 5 seconds are rarely acceptable, and having them be less than 1 second is desirable.
|
||||
|
||||
Consult your JVM vendor's documentation for specifics in your particular case, the recommendations above are intended as starting points.
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ _(raw; not yet edited)_
|
|||
* SOLR-13854, SOLR-13858: SolrMetricProducer / SolrInfoBean APIs have changed and third-party components that implement these APIs need to be updated. (ab)
|
||||
|
||||
* SOLR-13783: In situations where a NamedList must be output as plain text, commas between key-value pairs will now be
|
||||
followed by a space (e.g. {shape=square, color=yellow} rather than {shape=square,color=yellow}) for consistency with
|
||||
followed by a space (e.g., {shape=square, color=yellow} rather than {shape=square,color=yellow}) for consistency with
|
||||
other java.util.Map implementations based on AbstractMap (Chris Hennick).
|
||||
|
||||
* SOLR-13817: Legacy SolrCache implementations (LRUCache, LFUCache, FastLRUCache) have been removed.
|
||||
|
|
|
|||
|
|
@ -116,4 +116,4 @@ You can use your favourite git client to merge master into branch `production`.
|
|||
. Note: If there are other changes staged, you will see those as well if you merge `master` into `production`
|
||||
. Click the "Merge" button on the PR
|
||||
|
||||
The ordinary Solr release process will update the `LUCENE_LATEST_RELEASE` property of the website, which will ensure that Ref Guide URLs without a version in the path (e.g. `/solr/guide/mypage.adoc`) will automatically redirect to the latest Guide.
|
||||
The ordinary Solr release process will update the `LUCENE_LATEST_RELEASE` property of the website, which will ensure that Ref Guide URLs without a version in the path (e.g., `/solr/guide/mypage.adoc`) will automatically redirect to the latest Guide.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
= Rule-Based Authorization Plugin
|
||||
= Rule-Based Authorization Plugins
|
||||
// Licensed to the Apache Software Foundation (ASF) under one
|
||||
// or more contributor license agreements. See the NOTICE file
|
||||
// distributed with this work for additional information
|
||||
|
|
@ -16,7 +16,9 @@
|
|||
// specific language governing permissions and limitations
|
||||
// under the License.
|
||||
|
||||
Solr's authentication plugins control whether users can access Solr in a binary fashion. A user is either authenticated, or they aren't. For more fine-grained access control, Solr's Rule-Based Authorization Plugins (hereafter, "RBAP") can be used.
|
||||
Solr's authentication plugins control whether users can access Solr in a binary fashion.
|
||||
A user is either authenticated, or they aren't.
|
||||
For more fine-grained access control, Solr's Rule-Based Authorization Plugins (hereafter, "RBAP") can be used.
|
||||
|
||||
[CAUTION]
|
||||
====
|
||||
|
|
@ -118,7 +120,7 @@ This example `security.json` shows how the <<basic-authentication-plugin.adoc#ba
|
|||
|
||||
Altogether, this example carves out two restricted areas. Only `admin-user` can access Solr's Authentication and Authorization APIs, and only `dev-user` can access their `dev-private` collection. All other APIs are left open, and can be accessed by both users.
|
||||
|
||||
=== Example for ExternalRoleRuleBasedAuthorizationPlugin with JWT auth
|
||||
=== Example for External Role RuleBasedAuthorizationPlugin with JWT auth
|
||||
|
||||
This example `security.json` shows how the <<jwt-authentication-plugin.adoc#jwt-authentication-plugin,JWT authentication plugin>>, which pulls user and user roles from JWT claims, can work with the `ExternalRoleRuleBasedAuthorizationPlugin` plugin:
|
||||
|
||||
|
|
@ -139,9 +141,9 @@ This example `security.json` shows how the <<jwt-authentication-plugin.adoc#jwt-
|
|||
|
||||
Let's walk through this example:
|
||||
|
||||
<1> JWT Authentication plugin is enabled
|
||||
<2> Public keys is pulled over https
|
||||
<3> We expect each JWT token to contain a "roles" claim, which will be passed on to Authorization
|
||||
<1> JWT Authentication plugin is enabled.
|
||||
<2> Public keys will be pulled over HTTPS.
|
||||
<3> We expect each JWT token to contain a "roles" claim, which will be passed on to Authorization.
|
||||
<4> External Role Rule-based authorization plugin is enabled.
|
||||
<5> The 'admin' role has been defined, and it has permission to edit security settings.
|
||||
|
||||
|
|
|
|||
|
|
@ -38,6 +38,53 @@ Detailed steps for upgrading a Solr cluster are in the section <<upgrading-a-sol
|
|||
|
||||
If you are upgrading from 7.x, see the section <<Upgrading from 7.x Releases>> below.
|
||||
|
||||
=== Solr 8.6
|
||||
|
||||
See the https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote86[8.6 Release Notes]
|
||||
for an overview of the main new features of Solr 8.6.
|
||||
|
||||
When upgrading to 8.6.x users should be aware of the following major changes from 8.5.
|
||||
|
||||
*Support for Block-Max WAND*
|
||||
|
||||
Lucene added support for Block-Max WAND in 8.0, and 8.6 makes this available for Solr also.
|
||||
|
||||
It is enabled when using a new query parameter `minExactCount`.
|
||||
This parameter tells Solr to accurately count the number of hits accurately until at least this value.
|
||||
Once this value is reached, Solr can skip over documents that don't have a score high enough to be in the top set of documents, which has the potential for greatly speeding up searches.
|
||||
|
||||
It's important to note that when using this parameter, the hit count of searches may not be accurate.
|
||||
It is guaranteed that the hit count is accurate up to the value of `minExactCount`, but any returned hit count higher than that may be an approximation.
|
||||
|
||||
A new boolean attribute `numFoundExact` is included in all responses to indicate if the hit count in the response is expected to be exact or not.
|
||||
|
||||
More information about this new feature is available in the section <<common-query-parameters.adoc#minexactcount-parameter,minExactCount Parameter>>.
|
||||
|
||||
*Autoscaling*
|
||||
|
||||
* Solr now includes a default autoscaling policy.
|
||||
This policy can be overridden with your custom rules or by specifying an empty policy to replace the default.
|
||||
+
|
||||
For details of the default policy, see the section <<solrcloud-autoscaling-overview.adoc#cluster-policy,Cluster Policy>>.
|
||||
|
||||
* The <<solrcloud-autoscaling-trigger-actions.adoc#compute-plan-action,ComputePlan action>> now supports a collection selector to identify collections based on collection properties to determine which collections should be operated on.
|
||||
|
||||
*Security*
|
||||
|
||||
* A new authorization plugin `ExternalRoleRuleBasedAuthorizationPlugin` is now available.
|
||||
This plugin allows an authentication plugin (such as JWT) to supply a user's roles instead of maintaining a user-to-role mapping inside Solr.
|
||||
|
||||
* When authentication is enabled, the Admin UI Dashboard (main screen) now includes a panel that shows the authentication and authorization plugins in use, the logged in username, and the roles assigned to this user.
|
||||
A new link will also appear in the left-hand navigation to allow a user to log out.
|
||||
|
||||
*Streaming Expressions*
|
||||
|
||||
* The `/export` handler now supports streaming expressions to allow limiting the output of the export to only matching documents.
|
||||
+
|
||||
For more information about how to use this, see the section <<exporting-result-sets.adoc#specifying-the-local-streaming-expression,Specifying the Local Streaming Expression>>.
|
||||
|
||||
* The `stats`, `facet`, and `timeseries` expressions now support percentiles and standard deviation aggregations.
|
||||
|
||||
=== Solr 8.5
|
||||
|
||||
See the https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote85[8.5 Release Notes]
|
||||
|
|
@ -45,7 +92,7 @@ for an overview of the main new features of Solr 8.5.
|
|||
|
||||
When upgrading to 8.5.x users should be aware of the following major changes from 8.4.
|
||||
|
||||
__Note: an index incompatibility warning was retroactively added below to 8.4 for users choosing a non-default postings format (e.g. "FST50").__
|
||||
__Note: an index incompatibility warning was retroactively added below to 8.4 for users choosing a non-default postings format (e.g., "FST50").__
|
||||
|
||||
*Considerations for a SolrCloud Upgrade*
|
||||
|
||||
|
|
|
|||
|
|
@ -30,14 +30,14 @@ The following parameters are configurable:
|
|||
|
||||
`collections`::
|
||||
A comma-separated list of collection names, or a selector on collection properties that can be used to filter collections for which the plan is computed.
|
||||
|
||||
+
|
||||
If a non-empty list or selector is specified then the computed operations will only calculate collection operations that affect
|
||||
matched collections and ignore any other collection operations for collections
|
||||
not listed here. This does not affect non-collection operations.
|
||||
|
||||
A collection selector is of the form `collections: {key1: value1, key2: value2, ...}` where the key can be any collection property such as `name`, `policy`, `numShards` etc.
|
||||
+
|
||||
A collection selector is of the form `collections: {key1: value1, key2: value2, ...}` where the key can be any collection property such as `name`, `policy`, `numShards`, etc.
|
||||
The value must match exactly and all specified properties must match for a collection to match.
|
||||
|
||||
+
|
||||
A collection selector is useful in a cluster where collections are added and removed frequently and where selecting only collections that
|
||||
use a specific autoscaling policy is useful.
|
||||
|
||||
|
|
|
|||
|
|
@ -192,6 +192,6 @@ http://localhost:8983/solr/techproducts/select?q=*:*&fq={!tag=stock_check}inStoc
|
|||
|
||||
== The Stats Component and Faceting
|
||||
|
||||
Sets of `stats.field` parameters can be referenced by `'tag'` when using Pivot Faceting to compute multiple statistics at every level (i.e.: field) in the tree of pivot constraints.
|
||||
Sets of `stats.field` parameters can be referenced by `tag` when using Pivot Faceting to compute multiple statistics at every level (i.e., field) in the tree of pivot constraints.
|
||||
|
||||
For more information and a detailed example, please see <<faceting.adoc#combining-stats-component-with-pivots,Combining Stats Component With Pivots>>.
|
||||
|
|
|
|||
|
|
@ -276,7 +276,7 @@ The response should be this (the QTime may vary):
|
|||
* Follow the recommended configuration field settings above.
|
||||
Additionally, for the best tagger performance, set `postingsFormat=FST50`.
|
||||
However, non-default postings formats have no backwards-compatibility guarantees, and so if you upgrade Solr then you may find a nasty exception on startup as it fails to read the older index.
|
||||
If the input text to be tagged is small (e.g. you are tagging queries or tweets) then the postings format choice isn't as important.
|
||||
If the input text to be tagged is small (e.g., you are tagging queries or tweets) then the postings format choice isn't as important.
|
||||
* "optimize" after loading your dictionary down to 1 Lucene segment, or at least to as few as possible.
|
||||
* For bulk tagging lots of documents, there are some strategies, not mutually exclusive:
|
||||
** Batch them.
|
||||
|
|
|
|||
Loading…
Reference in New Issue