【问题标题】:Using an unique identifier in Solr indexed field name在 Solr 索引字段名称中使用唯一标识符
【发布时间】:2018-05-24 05:22:42
【问题描述】:

我的文档中有以下结构:

文档:1

{
  "123e4567-e89b-12d3-a456-426655440000": {
    "order_id": "100",
    "qty": 27
  },
  "321e7654-e89b-21d3-a654-426655441111": {
    "order_id": "234",
    "qty": 12
  }
}

文档:2

{
  "123e4567-e89b-12d3-a456-426655440000": {
    "order_id": "101",
    "qty": 27
  },
  "789ab763-a56b-87bb-a654-873655442222": {
    "order_id": "345",
    "qty": 23
  }
}

文档根中的uuid 代表客户标识符,嵌套对象代表客户下的订单。

我关心的唯一查询是通过客户标识符和订单标识符的单个字段进行简单查询,以找到他们的订单:

customer_idx?q=*:*&fq=123e4567-e89b-12d3-a456-426655440000.order_id:*&sort=123e4567-e89b-12d3-a456-426655440000.order_id asc&rows=3

或特定的:

customer_idx?q=*:*&fq=123e4567-e89b-12d3-a456-426655440000.order_id:101&rows=1

问题。在客户标识符上定义dynamicField 可以吗?从性能的角度。在这种情况下,我最终会得到特定模式的数十万或数百万个字段。

<dynamicField name="*.order_id" type="string" indexed="true" stored="false" multiValued="false" />

我知道,如果我在单个查询中使用其中的许多索引字段,则会对性能和内存消耗产生影响,因为 Lucene 会为我查询或排序的每个字段创建一个包含每个文档的一个项目的数组。但是如果有数十万或数百万个字段,我会同时查询其中一个,会不会有问题?

如果没有,有什么更好的解决方案?

谢谢。

UPDATE:更新的查询示例。添加了过滤器、排序和限制。以防万一。

【问题讨论】:

  • 你能详细说明一下吗,像这样的查询 q=123e4567-e89b-12d3-a456-426655440000:* 你已经有很多字段了,对吧?
  • 是的,现在有几十万个索引字段,Solr 的性能看起来还不错,到目前为止查询这样的速度超快。
  • 我更好奇,您是如何确定要查询哪个字段(例如 uuid)的?
  • 为什么会有问题?

标签: performance solr lucene solr-schema


【解决方案1】:

当您开始对结果集进行排序时,此类查询的主要问题就出现了。 FieldCache(如果您现在使用 docValues,您可能可以避免)将为索引中的每个文档填充一个关于其位置的 int(docid),即使只有少量文档有一个字段,将生成整个数组。有一个补丁可用于创建稀疏列表,仅列出那些确实包含该字段的文档。

无论如何,简单的解决方法是将您的数据结构转换为每个查询类型只使用一个字段:

customer_id:123e4567-e89b-12d3-a456-426655440000
customer_id_order_id:123e4567-e89b-12d3-a456-426655440000_101

.. 所以无论你有多少字段,你都会为每个字段获得一个缓存。

您还可以将文档分成两个单独的文档,一个用于每个 customer/order_id 组合,因此,将它们作为常规文档进行查询(而不是每个文档中有两个值)。

【讨论】:

  • 如果我理解正确,您描述的问题仅与大型结果集相关。如果我说按照设计每个客户最多有 10 个订单(结果集在最坏的情况下最多包含 10 个项目),FieldCache 仍然有问题吗?您能否详细说明它的工作原理或分享文档链接。
  • 如果您不对值进行排序或分面,则不会有问题 - FieldCache 主要用于排序(并且是 Solr 无能为力的 Lucene 概念) .在这些情况下,结果集中的文档数量无关紧要,只是总索引大小。 DocValues 也改变了这一点,IIRC。否则,您可能会从 Solr 的缓存中获得更多的缓存驱逐,因为 Solr 必须在内存中保留更多不同的结果集(您可以对此进行基准测试)。如果您没有发现任何问题,请继续使用它,并在出现问题时更换它。
猜你喜欢
  • 2015-12-16
  • 2010-11-01
  • 1970-01-01
  • 2013-04-13
  • 2011-09-24
  • 2019-01-01
  • 1970-01-01
  • 2015-06-16
  • 2015-11-18
相关资源
最近更新 更多