Lucene 编号提取

发布于 2024-07-17 14:17:02 字数 300 浏览 4 评论 0原文

我有这个号码提取问题。 我想要获取所有没有特定号码的比赛 例如:125501874、125001873 位置 2 处的所有数字如 55 均不予考虑。

第一个数字范围是 0 到 9,第二个数字范围是 1-9,因此实际范围是 [01-99] (我们不能将 00 作为前两个数字)

对于 Lucene,我想添加 NOT 字段:[01-99]55*

但它似乎不起作用。 有没有一种简单的方法可以找到 ??55* 并在搜索中忽略它(“NOT 字段:[01-99]55*”)?

谢谢Lucene大师

I have this number extracting problem.
I want to get all matches that don't have a certain number in it
ex : 125501874, 125001873
Every number that as 55 at the position 2 are not to be considered.

The first numbers range is 0 to 9 and the second is 1-9 so the real range is [01-99]
(we cannot have 00 as the first two number)

With Lucene I wanted to add NOT field:[01-99]55*

But it doesn't seem to work. Is there an easy way to find ??55* and disregard it in a Search("NOT field:[01-99]55*")?

Thank you Lucene guru

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

jJeQQOZ5 2024-07-24 14:17:03

如果创建一个仅包含第三个和第四个数字的“仅索引”字段,Lucene 可以非常有效地完成此操作。 完整的值可以“存储”(或者如果其他查询使用整数,则存储并索引)在原始字段中。


更新:后续评论问道:“有没有办法只在第二个数字上创建临时索引?”

使用 ParallelReader “垂直分区”索引的字段。 一个分区可以保存当前索引及其字段,而另一个分区是包含新字段的临时索引,可能存储在 RAMDirectory 中。

假设该数字“存储”在原始索引中,迭代原始索引中的每个文档,检索存储的字段,解析出关键数字,并使用新的文档将 Document 添加到临时索引场地。 正如 ParallelReader 文档所述,两个索引中的文档编号必须匹配。

Lucene can do this very efficiently if one creates an "index-only" field with only the third and fourth digits in it. The complete value can be "stored" (or stored and indexed if other queries use the whole number) in the original field.


Update: A followup comment asked, "Is [there] a way to create a temporary index on only the second digit?"

Using a ParallelReader "vertically partitions" the fields of an index. One partition could hold the current index, with its fields, while the other is a temporary index with the new field, possibly stored in a RAMDirectory.

Assuming the number is "stored" in the original index, iterate over each document in the original index, retrieve the stored field, parse out the key digits, and add a Document to the temporary index with the new field. As the ParallelReader documentation states, it is imperative that the document numbers match in both indexes.

欢你一世 2024-07-24 14:17:03

谢谢埃里克森,您的解决方案可能是最好的,如果我可以使用临时索引,则使用 ParallelReader,因为我们缓存搜索查询,稍后我们将需要它们。

但正如您之前所说,最好直接从相关数字的索引开始。

我有另一个解决方案。

NOT field:0?55*
NOT field:1?55*
...
NOT field:9?55*

它对于我正在进行的搜索来说足够有效,并且它绕过了第一个字符通配符限制。 如果要检查的数字更多或者距离起点更远,我不会使用它。
现在我正在一百万行上测试它,它对于我们的需求非常有效。

Thank you erickson, Your solution is probably the best, using ParallelReader if only I could use temporary indexes, cause we cache the search query, we will need those later.

But like you said before, better start with an index on the relevant digits straighaway.

I have another solution.

NOT field:0?55*
NOT field:1?55*
...
NOT field:9?55*

It is efficient enough for the search I'm doing and it bypass the first character wildcard limitation. I wouldn't use that if their where more digits to check or if they where farther from the start.
Now I'm testing this on a million of row and it's pretty efficient for our needs.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文