刚刚编写了一些有关模式的基本solr问题。
我的情况:以前有一个多核的solr实例,每个核心都包含不同的文档结构。虽然一个核心中的文档中的信息与其他不同核心中的文档相关,但是特定的法律约束迫使我们将这些数据保留在独立的实例中。因此,每次发出对solr实例的请求时,都会查询几个核心并将客户端应用程序“合并”并构建几个单独核心的响应。为了举例说明:假设我们是音乐商店,听起来很愚蠢,我们有CD的核心,DVD的核心,磁带的核心等,每个都有自己不同的架构;然后,当员工检查库存时,所有这些核心都会返回他们对员工计算机中应用程序的响应进行读取,处理不同的结构,并将结果显示为统一列表。
嗯,法律限制已被解除,我们现在正在将这些核心合并在一起,到目前为止,我们依赖于dynamicFields来提高架构的灵活性。然而,这带来了许多新的挑战和一些疑问:
1 - 什么更好:拥有数量减少的文档,每个文档都包含大量字段(我们在谈论数百个,偶尔会有数千个,所有已编入索引)或者将信息分散在几个小型文档中?从我在理论上阅读的内容来看,第一种方法是可取的,但我不认为任何一种情况都会考虑这一领域。
2 - 是否可以执行任何类型的关系搜索?我的意思是拥有以下文件:
<doc>
<ID>ALB@1234</ID>
<artist_t>Metallica</artist>
<album_t>Saint Anger</album>
</doc>
<doc>
<ID>PROD@12</ID>
<AlbID>ALB@1234</AlbID>
<format_t>CD</format_t>
<price_m>8.99</price_m>
</doc>
<doc>
<ID>PROD@13</ID>
<AlbID>ALB@1234</AlbID>
<format_t>MP3</format_t>
<price_m>3.99</price_m>
</doc>
然后在搜索Metallica时检索了所有三个文件?请记住,将最后两个文档的信息存储在第一个文件中作为多值文件的方法实际上并不是一种选择,因为据我所知,没有办法p.e.检索与价格匹配范围搜索的正确格式。
3 - 或者,是否可以将某种子文档结构定义为文档的一部分,如在多级文档中?同样,我不是指poly或multiValued字段,因为据我所知它们不适合更复杂和结构化的信息。是 思考一些事情:
<doc>
<ID>ALB@1234</ID>
<artist_t>Metallica</artist>
<album_t>Saint Anger</album>
<formats>
<format_x><ID>PROD@13</ID><AlbID>ALB@1234</AlbID><format_t>MP3</format_t><price_m>3.99</price_m></format_x>
<format_x><ID>PROD@12</ID><AlbID>ALB@1234</AlbID><format_t>CD</format_t><price_m>8.99</price_m></format_x>
</formats>
</doc>
4 - 考虑因素:当然,这种情况可以通过对2)中描述的模式进行建模并对服务器执行多个查询来解决,但这并不是最理想的解决方案。
期待任何评论或建议。抨击是不太受欢迎,但仍然可以接受,只是轻松我。 ;)如果这些问题听起来很愚蠢但我真的需要一些帮助,我很抱歉。
答案 0 :(得分:5)
这实际上取决于您希望如何构建数据以及您希望如何在数据上进行搜索 文档中的字段数量没有限制 如果您可以规范化同一文档中的数据,可以帮助您立即检索文档和所有相关详细信息。
对于关系搜索,Solr引入了一项功能Solr Join,它将帮助您加入文档 但是,这仅适用于Solr Trunk。因此,除非您可以使用Solr Trunk构建,否则这不适合您。
Solr没有子文档结构。但是,您可以尝试使用多值字段来映射内容。甚至使用分隔值。
<album>
<cd_id>
<str>cd_1</str>
<str>cd_2</str>
</cd_id>
<cd_price>
<str>cd_1_price</str>
<str>cd_2_price</str>
</cd_price>
</album>
应保持多值字段的顺序(因此您可以将cd_1映射到位置为1的cd_1_price)并且您应该能够在客户端重新创建数据。