date solr

Solr date campo tdate vs date?



(3)

Su mejor opción es mirar el código fuente. Algunas de las cosas para Solr no están bien documentadas y la forma más rápida de obtener una respuesta confiable es simplemente mirar el código. Si aún no ha estado en el código, eso también lo beneficia a usted. Al menos a la larga.

Aquí hay un enlace a 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

El javadoc en la clase al menos insinúa el objetivo de precisionStep. Podrías cavar más.

EDITAR: Cavé un poco más para ti. Se transmite directamente a la clase NumericTokenStream de Lucene, que utilizará el valor durante el análisis de la secuencia de token. Probablemente vale la pena un examen más detenido. Parece que se trata de la granularidad y es probablemente una compensación entre el tamaño en el índice y la velocidad.

Así que tengo una pregunta sobre los tipos de fechas de campo de Solr, que es bastante sencilla: ¿cuál es la diferencia entre un campo de ''fecha'' y un ''de fecha''?

El esquema .xml afirma que ''Para consultas de rango más rápidas, considere el tipo de fecha'' y ''Un campo de fecha basado en Tree para consultas de rango de fecha más rápidas y facetas de fecha. ''Justo lo suficiente ... pero ¿de qué se trata la precisionStep = "6"? ¿Debería cambiar esto? ¿Cambia la forma en que crearía la consulta en caso de que use la fecha? ¿Cuál es la ventaja real o qué hace Solr que lo hace mejor?

PD fue a través de Google, Solr manual, Solr wiki y los documentos de Java sin suerte, así que agradecería una respuesta amable y explicativa:) ... También revisado: http://www.lucidimagination.com/blog/2009/05 / 13 / exploring-lucene-and-solrs-trierange-capabilities / http://web.archiveorange.com/archive/v/AAfXfqRYyLnDFtskmLRi


Los campos Trie hacen que las consultas de rango sean más rápidas al precomputar ciertos resultados de rango y almacenarlos como un solo registro en el índice. Para mayor claridad, mi ejemplo usará enteros en la base diez. El mismo concepto se aplica a todos los tipos de trie. Esto incluye fechas, ya que una fecha se puede representar como el número de segundos desde, por ejemplo, 1970.

Digamos que indexamos el número 12345678 . Podemos tokenizar esto en los siguientes tokens.

12345678 123456xx 1234xxxx 12xxxxxx

El token 12345678 representa el valor entero real. Los tokens con los dígitos x representan rangos. 123456xx representa el rango 12345600 a 12345699 , y coincide con todos los documentos que contienen un token en ese rango.

Observe cómo en cada token en la lista tiene sucesivamente más x dígitos. Esto es controlado por el paso de precisión. En mi ejemplo, podría decir que estaba usando un paso de precisión de 2, ya que recorte 2 dígitos para crear cada ficha adicional. Si tuviera que usar un paso de precisión de 3, obtendría estos tokens.

12345678 12345xxx 12xxxxxx

Un paso de precisión de 4:

12345678 1234xxxx

Un paso de precisión de 1:

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

Es fácil ver cómo un paso de precisión más pequeño da como resultado más tokens y aumenta el tamaño del índice. Sin embargo, también acelera las consultas de rango.

Sin el campo trie, si quisiera consultar un rango de 1250 a 1275, Lucene tendría que buscar 25 entradas ( 1250 , 1251 , 1252 , ..., 1275 ) y combinar los resultados de la búsqueda. Con un campo trie (y un paso de precisión de 1), podríamos 125x 8 entradas ( 125x , 126x , 1270 , 1271 , 1272 , 1273 , 1274 , 1275 ), porque 125x es una agregación 125x de 1250 - 1259 . Si tuviera que usar un paso de precisión mayor que 1, la consulta volvería a buscar las 25 entradas individuales.

Nota: En realidad, el paso de precisión se refiere a la cantidad de bits recortados para cada token. Si tuviera que escribir sus números en hexadecimal, un paso de precisión de 4 recortaría un dígito hexadecimal para cada token. Un paso de precisión de 8 recortaría dos dígitos hexadecimales.


Buena pregunta :-) ! Leí una buena respuesta en alguna parte, lamentablemente no puedo encontrar esto de nuevo.

Básicamente, los rangos son más rápidos. Aquí hay una explicación. Con precisionStep usted configura cuánto puede crecer su índice para obtener los beneficios de rendimiento. Para citar del enlace al que se refiere:

"Más importante aún, no depende del tamaño del índice, sino de la precisión elegida".

y

"Los únicos inconvenientes de TrieRange son los tamaños de índice un poco más grandes, debido a los términos adicionales indexados"