Fecha del campo de fecha del Solr frente a la fecha?

Question

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

El esquema .xml afirma que 'Para consultas de rango más rápidas, considere el tipo de fecha y hora' y 'Un campo de fecha base basado para consultas de rango de fechas más rápidas y facetas de fecha. ' Bastante ... pero ¿de qué se trata la precisiónStep = "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?

PS fue a través de Google, manual de Solr, Solr wiki y la documentación de Java sin ninguna suerte hasta te agradecería una clase y respuesta explicativa:) ... También verificado: http://www.lucidimagination.com/blog/2009/05/13/exploring-lucene-and-solrs-trierange-capabilities/ http://web.archiveorange.com/archive/v/AAfXfqRYyLnDFtskmLRi

Answer 1

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

Básicamente, los intervalos son más rápidos. Here es 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 un poco más grandes tamaños de índice, debido a las condiciones adicionales indexados"

Answer 2

Su mejor la apuesta es simplemente 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 la 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 de la clase al menos insinúa la propósito de la precisionStep. Podrías cavar más.

EDITAR: Cavé un poco más para usted. 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.

Answer 3

campos Trie hacen rango consultas más rápidamente por la precomputación ciertos resultados de rango y almacenamiento ellos 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 cada token en la lista tiene sucesivamente más dígitos x. 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 precisión de 4:

12345678 
1234xxxx 

Un paso precisión de 1:

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

Es fácil ver cómo un paso de precisión menores resultados en más fichas y aumenta el tamaño del índice. Sin embargo, también acelera las consultas de rango.

Sin el campo trie, si quería consultar un rango de 1250 a 1275, Lucene tendría en busca de entradas (25 1250, 1251, 1252, ..., 1275) y combinar los resultados de búsqueda. Con un campo trie (y precisión de paso 1), podríamos ir a buscar salirse con 8 entradas (125x, 126x, 1270, 1271, 1272, 1273, 1274, 1275), porque 125x es una agregación de precomputed 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.