2011-01-07 17 views
32

Also ich habe eine Frage über Solr Felddatentypen, die ziemlich einfach ist: Was ist der Unterschied zwischen einem 'Datum' Feld und einem 'Tdate'?Solr Datum Feld tdate vs Datum?

Das Schema .xml behauptet, dass 'für schnellere Bereichsabfragen das Datumstyp' und 'ein Trier-basiertes Datumsfeld für schnellere Datumsbereichsabfragen und Datumsfacetten berücksichtigt werden. ' Gut genug ... aber worum geht es bei der Präzisionsstufe = "6"? sollte ich das ändern? Ändert es die Art, wie ich die Abfrage erstellen würde, falls ich das tdate verwende? Was ist der wirkliche Vorteil oder was macht Solr, das macht es besser?

PS ging durch google, Solr Handbuch, solr Wiki und die Java-Dokumentation ohne Erfolg, so würde ich eine Art und erläuternd Antwort schätzen:) ... auch geprüft: http://www.lucidimagination.com/blog/2009/05/13/exploring-lucene-and-solrs-trierange-capabilities/ http://web.archiveorange.com/archive/v/AAfXfqRYyLnDFtskmLRi

+4

5 Jahre später, immer noch die selbe Situation mit Google, Solr Handbuch, Solr Wiki, etc. Oh, nein, da hat sich etwas geändert: Google zeigt jetzt hier :) – alisa

Antwort

11

Gute Frage :-)! Ich lese irgendwo eine gute Antwort, finde das leider nicht wieder.

Grundsätzlich sind Trie-Bereiche schneller. Here ist eine Erklärung. Mit precisionStep konfigurieren Sie, wie stark Ihr Index wachsen kann, um die Leistungsvorteile zu erhalten. Um von dem angegebenen Link zu zitieren:

"Wichtiger ist, dass es nicht von der Indexgröße abhängt, sondern von der gewählten Genauigkeit."

und

„die einzigen Nachteile von TrieRange sind ein wenig größer Indexgrößen, aufgrund der zusätzlichen Begriffe indiziert“

3

Ihre beste Wette ist, nur auf den Quellcode zu schauen. Einige der Dinge für Solr sind nicht gut dokumentiert und der schnellste Weg, um eine vertrauenswürdige Antwort zu erhalten, ist einfach auf den Code zu schauen. Wenn Sie noch nicht im Code waren, ist das auch zu Ihrem Vorteil. Zumindest auf lange Sicht.

Hier ist ein Link zu der 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

Die Javadoc- in der Klasse bei deutet dest an den Zweck der precisionStep. Du könntest weiter graben.

EDIT: Ich habe ein bisschen mehr für Sie gegraben. Es wird direkt an die NumericTokenStream-Klasse von Lucene übergeben, die den Wert beim Parsen des Token-Streams verwendet. Wahrscheinlich eine nähere Untersuchung wert. Es scheint sich um Granularität zu handeln und ist wahrscheinlich ein Kompromiss zwischen Größe im Index und Geschwindigkeit.

+0

Ordentlich, danke für die Antworten ... Ich habe auch ein nettes gefunden Post in Lucene Foren, die ein bisschen mehr klären, was ist der Deal mit dem tdate ... Anscheinend ist es nur die Art, wie Solr indiziert das Feld und die Größe davon: http://lucene.472066.n3.nabble.com /Best-performance-for-facet-dates-in-trunk-using-solr-TrieDateField-td487668.html Abgesehen von der Indexgröße und den leistungsweisen Optionen habe ich keine anderen Sachen gefunden, die geändert werden müssten falls Sie die Option tdate verwenden. –

37

Trie Felder machen Bereichsabfragen schneller durch precomputing bestimmten Bereich Ergebnisse und Speicherung sie als einzelner Datensatz im Index. Zur besseren Übersicht verwendet mein Beispiel Ganzzahlen in der Basis zehn. Dasselbe Konzept gilt für alle Trie-Typen. Dies beinhaltet Datumsangaben, da ein Datum als Anzahl von Sekunden seit etwa 1970 dargestellt werden kann.

Nehmen wir an, wir indexieren die Nummer 12345678. Wir können dies in die folgenden Tokens einteilen.

12345678 
123456xx 
1234xxxx 
12xxxxxx 

Das Token 12345678 repräsentiert den tatsächlichen ganzzahligen Wert. Die Token mit den Ziffern x repräsentieren Bereiche.123456xx repräsentiert den Bereich 12345600 bis 12345699 und stimmt mit allen Dokumenten überein, die ein Token in diesem Bereich enthalten.

Beachten Sie, wie in jedem Token auf der Liste nacheinander x Ziffern. Dies wird durch den Präzisionsschritt gesteuert. In meinem Beispiel könnte man sagen, dass ich einen Präzisionsschritt von 2 verwendet habe, da ich zwei Ziffern trimme, um jedes zusätzliche Token zu erstellen. Wenn ich einen Präzisionsschritt von 3 verwenden würde, würde ich diese Token bekommen.

12345678 
12345xxx 
12xxxxxx 

Ein Präzisions-Schritt von 4:

12345678 
1234xxxx 

Ein Präzisions Schritt 1:

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

Es ist einfach in mehr Token ein kleineren Ergebnisse Präzision Schritt, um zu sehen, wie und erhöht die Größe des Indexes. Es beschleunigt jedoch auch Bereichsabfragen.

Ohne den Trie-Bereich, wenn ich einen Bereich von 1250 bis 1275, Lucene müßten holen 25 Einträge (1250, 1251, 1252, ..., 1275) und kombiniert die Suchergebnisse abfragen will. Mit einem Trie-Feld (und Präzision Schritt 1), konnten wir mit Abrufen 8 Einträge weg (125x, 126x, 1270, 1271, 1272, 1273, 1274, 1275), weil 125x ist eine vorberechnete Aggregation von 1250-1259. Wenn ich einen Präzisionsschritt größer als 1 verwenden würde, würde die Abfrage alle 25 einzelnen Einträge abrufen.

Hinweis: In Wirklichkeit bezieht sich der Präzisionsschritt auf die Anzahl der für jedes Token getrimmten Bits. Wenn Sie Ihre Zahlen hexadezimal schreiben würden, würde ein Präzisionsschritt von 4 eine Hexadezimalziffer für jedes Token trimmen. Ein Präzisionsschritt von 8 würde zwei Hexadezimalziffern abschneiden.

+1

Super Erklärung. Ich habe stundenlang gelesen und versucht, Präzisionsschritte zu verstehen, und dies ist die erste Erklärung, die Sinn ergab. –

+0

Beachten Sie, dass Sekunden seit 1970 nicht nur ein theoretischer Weg ist. Es ist in der Tat die Art und Weise, wie es gemacht wird, und wenn Sie ein Null-Datum-Feld haben, wird es 0 Sekunden von 1970 betrachtet. Das Ergebnis ist null und nicht Null Trie Datum Felder ist schrecklich. Sie erhalten Daten vor 1970, Nullwerte, dann Daten nach 1970. – mlissner