Apache Solr 过滤不起作用但可以通过 id 检索
Apache Solr filtering not working but possible to retrieve by id
背景:
我们有一个迁移到 docker 的 3 节点 solr 云。它按预期工作,但是,对于插入的新数据,它只能通过 id 检索。一旦我们尝试使用过滤器,它就不会显示。请注意,仍然可以毫无问题地过滤旧数据。
数据库通过 spring-boot crud-like 应用程序使用。
更多背景:
app和solr是别人迁移过来的,我最近继承了代码库,所以我对实现的细节不是很熟悉,还在挖掘和调试中。
节点按原样迁移(数据被复制到 docker 安装)。
我目前有:
我检查了所有 solr 节点的日志,发现在调用应用程序时发生了以下情况:
过滤:
2019-02-22 14:17:07.525 INFO (qtp15xxxxx-15) [c:content_api s:shard1 r:core_node1 x:content_api_shard1_replica0] o.a.s.c.S.Request
[content_api_shard1_replica0]
webapp=/solr path=/select
params=
{q=*:*&start=0&fq=id-lws-ttf:127103&fq=active-boo-ttf:(true)&fq=(publish-date-tda-ttf:[*+TO+2019-02-22T15:17:07Z]+OR+(*:*+NOT+publish-date-tda-ttf:[*+TO+*]))AND+(expiration-date-tda-ttf:[2019-02-22T15:17:07Z+TO+*]+OR+(*:*+NOT+expiration-date-tda-ttf:[*+TO+*]))&sort=create-date-tda-ttf+desc&rows=10&wt=javabin&version=2}
hits=0 status=0 QTime=37
通过ID获取:
2019-02-22 14:16:56.441 INFO (qtp15xxxxxx-16) [c:content_api s:shard1 r:core_node1 x:content_api_shard1_replica0] o.a.s.c.S.Request
[content_api_shard1_replica0]
webapp=/solr path=/get params={ids=https://example.com/app/contents/127103/middle-east&wt=javabin&version=2}
status=0 QTime=0
免责声明:
我是使用 Solr 的绝对初学者,正在阅读文档 ATM 以便更好地了解具体细节。
假设和 WIP:
迁移的人告诉我,只复制了数据,没有复制配置。我已经获得了旧的配置文件 (/opt/solr/server/solr/configsets/
) 并正在尝试与新的进行比较。但假设配置是默认配置。
旧版本是 6.4.2
,新版本是 6.6.5
(不确定这可能是问题所在)
这里有什么明显的遗漏吗?超级令人困惑的是可以通过 id 检索数据并且可以过滤旧数据
更新:
- 经过一些研究,我不得不说我已经排除了配置问题,因为当我从管理员 UI 检查配置时,我看到了正确的配置。
- 另外,还有一个奇怪的现象就是数据过一段时间(比如5天以上)才能查询到。我可以看到,因为我 运行 来自 UI 的查询并按降序创建日期对其进行排序。从那里,我可以看到我不仅仅是几天前的测试
相关提交配置部分:
<autoCommit>
<maxTime>${solr.autoCommit.maxTime:15000}</maxTime>
<openSearcher>false</openSearcher>
</autoCommit>
<autoSoftCommit>
<maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime>
</autoSoftCommit>
来自管理端点的更多配置输出:
config:{
znodeVersion:0,
luceneMatchVersion:"org.apache.lucene.util.Version:6.0.1",
updateHandler:{
indexWriter:{
closeWaitsForMerges:true
},
commitWithin:{
softCommit:true
},
autoCommit:{
maxDocs:-1,
maxTime:15000,
openSearcher:false
},
autoSoftCommit:{
maxDocs:-1,
maxTime:-1
}
},
query:{
useFilterForSortedQuery:false,
queryResultWindowSize:20,
queryResultMaxDocsCached:200,
enableLazyFieldLoading:true,
maxBooleanClauses:1024,
filterCache:{
autowarmCount:"0",
size:"512",
initialSize:"512",
class:"solr.FastLRUCache",
name:"filterCache"
},
queryResultCache:{
autowarmCount:"0",
size:"512",
initialSize:"512",
class:"solr.LRUCache",
name:"queryResultCache"
},
documentCache:{
autowarmCount:"0",
size:"512",
initialSize:"512",
class:"solr.LRUCache",
name:"documentCache"
},
:{
size:"10000",
showItems:"-1",
initialSize:"10",
name:"fieldValueCache"
}
},
...
听起来您可能已在升级时切换到默认托管架构。在您之前的安装中查找 schema.xml 以及您之前安装的 solrconfig.xml 中的一个部分。更多信息请访问 https://lucene.apache.org/solr/guide/6_6/schema-factory-definition-in-solrconfig.html#SchemaFactoryDefinitioninSolrConfig-SolrUsesManagedSchemabyDefault
根据您的示例,您仅在查询实时获取端点时才检索文档 - 即 /get
。此端点 returns 通过按 id 查询来记录文档,即使文档尚未提交到索引或已打开新的搜索器也是如此。
在索引的任何更改对常规搜索端点可见之前,必须创建一个新的搜索器,因为旧的搜索器仍将使用旧的索引文件进行搜索。如果未创建新的搜索器,过时的内容仍将返回。这与您看到的行为相符,您没有打开任何新的搜索器,并且当搜索器因其他原因被回收时内容变得可见(可能是因为 restarts/another 显式 commit/merges/optimizes/etc。)。 =12=]
您的示例配置显示 autoSoftCommit 被禁用,而常规 autoCommit 设置为不打开新的搜索器(因此,没有显示新内容)。我通常建议禁用此功能,而是依赖于在 URL 中使用 commitWithin
,因为它允许对不同类型的数据进行更大的可配置性,并允许您要求至少在 x 内打开一个新的搜索器添加数据后的秒数。 commitWithin 的默认行为是在提交发生后将打开一个新的搜索器。
背景: 我们有一个迁移到 docker 的 3 节点 solr 云。它按预期工作,但是,对于插入的新数据,它只能通过 id 检索。一旦我们尝试使用过滤器,它就不会显示。请注意,仍然可以毫无问题地过滤旧数据。
数据库通过 spring-boot crud-like 应用程序使用。
更多背景:
app和solr是别人迁移过来的,我最近继承了代码库,所以我对实现的细节不是很熟悉,还在挖掘和调试中。 节点按原样迁移(数据被复制到 docker 安装)。
我目前有:
我检查了所有 solr 节点的日志,发现在调用应用程序时发生了以下情况:
过滤:
2019-02-22 14:17:07.525 INFO (qtp15xxxxx-15) [c:content_api s:shard1 r:core_node1 x:content_api_shard1_replica0] o.a.s.c.S.Request
[content_api_shard1_replica0]
webapp=/solr path=/select
params=
{q=*:*&start=0&fq=id-lws-ttf:127103&fq=active-boo-ttf:(true)&fq=(publish-date-tda-ttf:[*+TO+2019-02-22T15:17:07Z]+OR+(*:*+NOT+publish-date-tda-ttf:[*+TO+*]))AND+(expiration-date-tda-ttf:[2019-02-22T15:17:07Z+TO+*]+OR+(*:*+NOT+expiration-date-tda-ttf:[*+TO+*]))&sort=create-date-tda-ttf+desc&rows=10&wt=javabin&version=2}
hits=0 status=0 QTime=37
通过ID获取:
2019-02-22 14:16:56.441 INFO (qtp15xxxxxx-16) [c:content_api s:shard1 r:core_node1 x:content_api_shard1_replica0] o.a.s.c.S.Request
[content_api_shard1_replica0]
webapp=/solr path=/get params={ids=https://example.com/app/contents/127103/middle-east&wt=javabin&version=2}
status=0 QTime=0
免责声明:
我是使用 Solr 的绝对初学者,正在阅读文档 ATM 以便更好地了解具体细节。
假设和 WIP:
迁移的人告诉我,只复制了数据,没有复制配置。我已经获得了旧的配置文件 (
/opt/solr/server/solr/configsets/
) 并正在尝试与新的进行比较。但假设配置是默认配置。旧版本是
6.4.2
,新版本是6.6.5
(不确定这可能是问题所在)
这里有什么明显的遗漏吗?超级令人困惑的是可以通过 id 检索数据并且可以过滤旧数据
更新:
- 经过一些研究,我不得不说我已经排除了配置问题,因为当我从管理员 UI 检查配置时,我看到了正确的配置。
- 另外,还有一个奇怪的现象就是数据过一段时间(比如5天以上)才能查询到。我可以看到,因为我 运行 来自 UI 的查询并按降序创建日期对其进行排序。从那里,我可以看到我不仅仅是几天前的测试
相关提交配置部分:
<autoCommit>
<maxTime>${solr.autoCommit.maxTime:15000}</maxTime>
<openSearcher>false</openSearcher>
</autoCommit>
<autoSoftCommit>
<maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime>
</autoSoftCommit>
来自管理端点的更多配置输出:
config:{
znodeVersion:0,
luceneMatchVersion:"org.apache.lucene.util.Version:6.0.1",
updateHandler:{
indexWriter:{
closeWaitsForMerges:true
},
commitWithin:{
softCommit:true
},
autoCommit:{
maxDocs:-1,
maxTime:15000,
openSearcher:false
},
autoSoftCommit:{
maxDocs:-1,
maxTime:-1
}
},
query:{
useFilterForSortedQuery:false,
queryResultWindowSize:20,
queryResultMaxDocsCached:200,
enableLazyFieldLoading:true,
maxBooleanClauses:1024,
filterCache:{
autowarmCount:"0",
size:"512",
initialSize:"512",
class:"solr.FastLRUCache",
name:"filterCache"
},
queryResultCache:{
autowarmCount:"0",
size:"512",
initialSize:"512",
class:"solr.LRUCache",
name:"queryResultCache"
},
documentCache:{
autowarmCount:"0",
size:"512",
initialSize:"512",
class:"solr.LRUCache",
name:"documentCache"
},
:{
size:"10000",
showItems:"-1",
initialSize:"10",
name:"fieldValueCache"
}
},
...
听起来您可能已在升级时切换到默认托管架构。在您之前的安装中查找 schema.xml 以及您之前安装的 solrconfig.xml 中的一个部分。更多信息请访问 https://lucene.apache.org/solr/guide/6_6/schema-factory-definition-in-solrconfig.html#SchemaFactoryDefinitioninSolrConfig-SolrUsesManagedSchemabyDefault
根据您的示例,您仅在查询实时获取端点时才检索文档 - 即 /get
。此端点 returns 通过按 id 查询来记录文档,即使文档尚未提交到索引或已打开新的搜索器也是如此。
在索引的任何更改对常规搜索端点可见之前,必须创建一个新的搜索器,因为旧的搜索器仍将使用旧的索引文件进行搜索。如果未创建新的搜索器,过时的内容仍将返回。这与您看到的行为相符,您没有打开任何新的搜索器,并且当搜索器因其他原因被回收时内容变得可见(可能是因为 restarts/another 显式 commit/merges/optimizes/etc。)。 =12=]
您的示例配置显示 autoSoftCommit 被禁用,而常规 autoCommit 设置为不打开新的搜索器(因此,没有显示新内容)。我通常建议禁用此功能,而是依赖于在 URL 中使用 commitWithin
,因为它允许对不同类型的数据进行更大的可配置性,并允许您要求至少在 x 内打开一个新的搜索器添加数据后的秒数。 commitWithin 的默认行为是在提交发生后将打开一个新的搜索器。