Solr日期字段tdate vs日期？

Question

所以我有一個關於Solr的字段日期類型的問題，它非常簡單：'date'字段和'tdate'字段之間有什麼區別？

模式.xml聲稱'對於更快的範圍查詢，請考慮tdate類型'和'基於Trie的日期字段以加快日期範圍查詢和日期刻面。 ' 夠了......但是precisionStep =「6」又是什麼意思？我應該改變這個嗎？它是否會改變我在使用tdate的情況下創建查詢的方式？真正的優勢是什麼？Solr做的是什麼讓它變得更好？

PS通過谷歌，Solr的手冊，Solr的維基和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範圍更快。 Here是一個解釋。通過precisionStep，您可以配置索引的增長量以獲得性能優勢。引用你所指的鏈接：

「更重要的是，它不依賴於索引大小，而是取決於所選精度。」

和

「TrieRange的唯一缺點是稍微較大的索引的大小，因爲索引的附加術語」

Answer 2

你最好的打賭是看看源代碼。 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類，該類將在解析令牌流時使用該值。可能值得仔細檢查。它似乎處理的是粒度，可能是索引大小和速度之間的折衷。

Answer 3

Trie樹字段使範圍通過預先計算一定範圍內的結果和存儲查詢更快他們作爲索引中的單個記錄。爲了清楚起見，我的示例將使用十進制的整數。相同的概念適用於所有特里特類型。這包括日期，因爲日期可以表示爲1970年以來的秒數。

比方說，我們將索引編號爲12345678。我們可以將其標記爲以下標記。

12345678 
123456xx 
1234xxxx 
12xxxxxx 

該標記代表實際的整數值。帶有x數字的令牌表示範圍。123456xx代表12345600至12345699的範圍，並匹配包含該範圍內令牌的所有文檔。

請注意，列表中的每個令牌如何連續更多x數字。這由精確度步驟控制。在我的例子中，你可以說我正在使用2的精確度，因爲我修剪了2位數字來創建每個額外的令牌。如果我使用3的精確度，我會得到這些令牌。

12345678 
12345xxx 
12xxxxxx 

的精度爲4步驟：

12345678 
1234xxxx 

的1的精度步驟：

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

可以很容易地看到較小的精度步驟導致更多的標記，並增加了尺寸的指數。但是，它也加快了範圍查詢。

沒有線索場，如果我想查詢範圍1250至1275年，Lucene的必須取25個條目（1250，1251，1252，...，1275），並結合搜索結果。隨着特里場（與1精密步進），我們可以擺脫獲取8項（125x，126x，1270，1271，1272，1273，1274，1275），因爲125x是1250預先計算聚合 - 1259。如果我使用大於1的精度步長，則查詢將返回獲取所有25個單獨的條目。

注意：實際上，精度步驟是指每個令牌修剪的位數。如果您要以十六進制編寫您的數字，則精確步長爲4會爲每個標記修正一個十六進制數字。精度爲8的步驟將修剪兩個十六進制數字。