Solr日期字段tdate与日期？

Question

所以我对 Solr 的字段日期类型有一个非常直接的问题：“日期”字段和“tdate”字段有什么区别？

架构 .xml 声称“对于更快的范围查询，请考虑 tdate 类型”和“基于 Trie 的日期字段，以实现更快的日期范围查询和日期分面。 ' 很公平......但是precisionStep =“6”到底是什么？我应该改变这个吗？如果我使用 tdate，它会改变我创建查询的方式吗？真正的优势是什么，或者 Solr 做了什么让它变得更好？

P.S 浏览了谷歌、Solr 手册、solr wiki 和 java 文档，但没有任何运气，所以我很感激一个友好和解释性的答案:)... 还检查了： http://www.lucidimagination.com/blog/2009/05/13/exploring-lucene-and-solrs-trierange-capabilities/ http://web.archiveorange.com/archive/v/AAfXfqRYyLnDFtskmLRi

Answer 1

Trie 字段通过预先计算某些范围结果并将它们作为单个记录存储在索引中来加快范围查询。为清楚起见，我的示例将使用以十为底的整数。相同的概念适用于所有 trie 类型。这包括日期，因为日期可以表示为自 1970 年以来的秒数。

假设我们索引号码12345678。我们可以将其标记为以下标记。

12345678
123456xx
1234xxxx
12xxxxxx

12345678 标记代表实际的整数值。带有x 数字的标记表示范围。 123456xx 代表12345600 到12345699 的范围，并匹配包含该范围内的令牌的所有文档。

请注意列表中的每个标记如何依次具有更多的x 数字。这由精度步长控制。在我的示例中，您可以说我使用了 2 的精度步长，因为我修剪 2 位数字来创建每个额外的标记。如果我使用 3 的精度步长，我会得到这些标记。

12345678
12345xxx
12xxxxxx

精度步长为 4：

12345678
1234xxxx

精度步长为 1：

12345678
1234567x
123456xx
12345xxx
1234xxxx
123xxxxx
12xxxxxx
1xxxxxxx

很容易看出更小的精度步长如何产生更多的标记并增加索引的大小。但是，它也加快了范围查询。

如果没有 trie 字段，如果我想查询从 1250 到 1275 的范围，Lucene 必须获取 25 个条目（1250、1251、1252、...、1275）并结合搜索结果。使用 trie 字段（精度步长为 1），我们可以轻松获取 8 个条目（125x、126x、1270、1271、1272、1273、1274、@ 987654343@)，因为125x 是1250 - 1259 的预计算聚合。如果我使用大于 1 的精度步长，则查询将返回到获取所有 25 个单独的条目。

注意：实际上，精度步长是指为每个标记修剪的位数。如果您要以十六进制编写数字，则精度为 4 的步长将为每个标记修剪一个十六进制数字。 8 的精度步长将修剪两个十六进制数字。

Answer 2

基本上 trie 范围更快。 Here 是一种解释。使用precisionStep，您可以配置索引可以增长多少以获得性能优势。引用您所指的链接：

更重要的是，它不依赖于索引大小，而是选择的精度。

和

TrieRange 唯一的缺点是索引大小有点大，因为索引的附加术语

Answer 3

最好的办法是只查看源代码。 Solr 的某些内容没有很好的文档记录，获得可靠答案的最快方法是简单地查看代码。如果您还没有参与过代码，那也对您有利。至少从长远来看。

这里是 TrieTokenizerFactory 的链接。

http://www.jarvana.com/jarvana/view/org/apache/solr/solr-core/1.4.1/solr-core-1.4.1-sources.jar!/org/apache/solr/analysis/TrieTokenizerFactory.java?format=ok

类中的 javadoc 至少暗示了precisionStep 的目的。你可以进一步挖掘。

编辑：我为您挖掘了更多内容。它直接传递给 Lucene 的 NumericTokenStream 类，该类将在解析令牌流期间使用该值。可能值得仔细研究。它似乎处理粒度，可能是索引大小和速度之间的权衡。