2015-03-02 34 views
0

我使用Solr来索引不同类型的产品。产品类型(类别)有不同的方面。例如:Solr支持不同类型产品的不同刻面

camera: megapixel, type (slr/..), body construction, .. 
processors: no. of cores, socket type, speed, type (core i5/7) 
food: type, origin, shelf-life, weight 
tea: type (black/green/white/..), origin, weight, use milk? 
serveware: type, material, color, weight 
... 

而且他们有共同的方面还有:

Brand, Price, Discount, Listing timeframe (like new), Availability, Category 

我需要在用户点击任何类别或品牌页面或跨所有全局搜索显示相关面和面包屑产品类型。这与我们在几个电子商务网站上看到的相同。

我拥有的查询是: 由于方面类型在不同类型的产品中或多或少都是唯一的,我可以将它们放在单独的模式中吗?这是做到这一点的方式吗?根本的担心是这些字段不会有其他类型的产品的任何数据。这里有没有任何实现原则可以让检索给定产品类型的相应面更容易?

我希望有一个可扩展的设计,以适应每种产品类型中的大量项目,并且如果可能的话,它易于使用和面向性能。现在我有一个Solr实例。

+0

应该不需要设置多个Solr实例,但是实现的部分原因是您是否事先知道用户正在搜索哪个类别。这应该都可以在单个Solr索引中以任何方式进行管理,但如果您知道这一点,则实现将更加高效和简单。 – frances 2015-03-03 00:55:22

+0

无论这个问题如何,它可能有助于了解'solrconfig.xml'包含查询时间信息,因此可以在不进行重新索引的情况下进行更改,并且它可能包含针对单个Solr索引的多个请求处理程序。您的构面选项可以在solrconfig.xml的请求处理程序中或在查询url本身中进行配置。只要所有可能的方面字段都被索引(由'schema.xml'确定)用于分面,这意味着同时具有'indexed =“true”,那么您可以在查询时确定您感兴趣的方面, '和'stored =“true”'。 – frances 2015-03-03 00:55:31

+0

@frances感谢您的意见。所以你说的是一个schema.xml,有n个facet字段,但大多数没有被填充(基于产品类型和它们的方面),这绝对是一个可接受的设计? – Ethan 2015-03-03 01:15:31

回答

1

人口不足的唯一风险是当他们歪曲搜索时。我相信你已经使用了一个搜索网站,你想要的元数据被人口稀少,所以当你应用这个方面时,你也会从结果集中消除应该包含的许多记录。需要注意的是,方面值始终在适当的位置填充。这意味着您的“茶”记录不需要列出大量内核,也不会影响任何内容,但是所有“处理器”记录都应该(并且在任何可能的程度上)都应该一致地填充。这意味着,如果一个处理器将其核心数量列为“4”,而另一个处理器将其称为“quadcore”,则这是两个不同的值,应用这两个分面值的用户将消除其结果中的其他处理器。如果第三个四核处理器完全缺少no_cores构面字段中的“核心数”统计信息(字段名称是任意的),那么您的方面可能会适得其反。

因此,我们可以将所有这些记录放到同一个Solr中,只要这些方面在适当的位置一致地填充,它们并非真的有必要为所有记录填充,特别是在不适用时。

应用方面动态

大多数时候,你需要知道什么是Solr中的faceting文档。重要的是在你的查询中指定适当的参数来告诉Solr你想要使用的方面。 (直到你真正面对一个领域,这不是一个方面,而只是一个领域,这两个领域都是stored="true"indexed="true"。)对于一个非常动态的效果,你可以指定所有这些参数作为对Solr查询的一部分。

&facet=true 

这看起来很明显,但您需要打开刻面。这个参数很方便,因为它也允许你关掉关闭facet=false分开,即使你的查询中有很多其他参数详细说明如何来面向。如果刻面关闭,它没有任何作用。

&facet.field=no_cores 

您可以为您感兴趣的小平面上一遍又一遍包括这一领域的许多领域。

&facet.limit=7 
&f.no_cores.facet.limit=4 

第一行这里限制值的数量为7。为小(在搜索结果中)的7个最常见的值将被退回,与他们的记录计数每个面外地回来的Solr的。第二行特别覆盖no_cores字段的此限制。

&facet.sort=count 

您可以在多少记录(count),或在索引顺序(index)由多少显得列出的顺序方面字段的值。索引顺序通常意味着按字母顺序排列,但取决于该字段的索引方式。此字段与facet.limit一起使用,因此,如果返回的构面值数量受facet.limit限制,则它们将是结果集中最多的值或索引中最早的值,具体取决于设置该值的方式。

&facet.mincount=1 

有迹象表明,你将要看到,在搜索结果中出现零次小值非常少的情况下,如果它会弹出这样可以解决问题。

最终的结果是一个很长的查询:

http://localhost/solr/collecion1/search?facet=true&facet.field=no_cores& 
facet.field=socket_type&facet.field=processor_type&facet.field=speed& 
facet.limit=7&f.no_cores.facet.limit=4&facet.mincount=1&defType=dismax& 
qf=name,+manufacturer,+no_cores,+description& 
fl=id,name,no_cores,description,price,shipment_mode&q="Intel" 

这肯定是有效的,并允许决策有关搜索应该如何工作的即时量最大的,但是,这不是”对于调试非常可读。

应用方面较少动态

等等这些功能允许您指定要小面了哪些字段,并动态地做到这一点。但是,它可能会导致很多非常漫长而复杂的查询,特别是如果您在几种不同的搜索模式中使用了许多方面。

一种选择是在solrconfig.xml的请求处理程序中正式确定每组常用选项。这样,您可以应用完全相同的参数,而不是在每个查询中列出所有参数,而只需指定您想要的请求处理程序。

<requestHandler name="/processors" class="solr.SearchHandler"> 
<lst name="defaults"> 
    <str name="defType">dismax</str> 
    <str name="echoParams">explicit</str> 
    <str name="fl">id,name,no_cores,description,price,shipment_mode</str> 
    <str name="qf">name, manufacturer, no_cores, description</str> 
    <str name="sort">score desc</str> 
    <str name="rows">30</str> 
    <str name="wt">xml</str> 
    <str name="q.alt">*</str> 
    <str name="facet.mincount">1</str> 
    <str name="facet.field">no_cores</str> 
    <str name="facet.field">socket_type</str> 
    <str name="facet.field">processor_type</str> 
    <str name="facet.field">speed</str> 
    <str name="facet.limit">10</str> 
    <str name="facet.sort">count</str> 
</lst> 
<lst name="appends"> 
    <str name="fq">category:processor</str> 
</lst> 
</requestHandler> 

如果你设置了一个请求,左撇子在solrconfig.xml,它的作用是作为一组查询参数的简写。您可以根据需要为单个索引索引提供尽可能多的请求处理程序,并且可以在不重建索引的情况下对其进行更改(重新加载Solr内核或重新启动服务器应用程序(例如JBoss或Tomcat)以使更改生效)。

这个请求处理程序有很多事情我没有涉及,但它只是一种表示默认Solr请求参数的方法,因此您的实时查询可以更简单。通过这种方式,你可以进行查询,如:

http://localhost/solr/collection1/processors?q="Intel" 

返回与所有填充特定处理器方面的结果集,和过滤,以便只返回处理器的记录。 (这是category:processor筛选器,它假定一个名为category的字段,其中所有处理器记录的值为processor。这完全是可选的,并且取决于您。)您可能希望保留默认搜索请求处理程序,该处理程序不会按照记录类别进行过滤,并且可能不会选择将任何可用(stored="true"indexed="true")字段应用为活动方面。

+0

真的很感谢你的描述性答案。如果我需要任何澄清,将会通过它并让你知道。同时我也一直在探索这个。我遇到了使用dynamicField的问题,重复使用预定义字段的机会以及枢轴和相关面包屑的概念。一个有趣的文档,我一直在阅读:http://rhizomik.net/html/~roberto/papers/IJSWIS-SIVisualisationandInteraction.pdf和http://lucene.472066.n3.nabble.com/Solr-Dynamic-Field-性能td4158737.html – Ethan 2015-03-03 22:52:51