Поле даты датца sr Дата и дата?

Итак, у меня есть вопрос о типах полей типа Solr, который довольно прямолинейный: какая разница между полем "дата" и "tdate"?

Схема .xml утверждает, что "для запросов с более высоким диапазоном, рассмотрите тип tdate и поле даты на основе Trie для более быстрых запросов диапазона дат и датирования. ' Достаточно справедливо... но что такое precisionStep = "6"? я должен это изменить? изменяет ли он способ создания запроса в случае использования tdate? Какое реальное преимущество или что делает Solr, делает это лучше?

P.S прошли через google, Solr manual, solr wiki и java-документы без всякой удачи, поэтому я буду благодарен за добрый и пояснительный ответ:)... Также проверено: http://www.lucidimagination.com/blog/2009/05/13/exploring-lucene-and-solrs-trierange-capabilities/ http://web.archiveorange.com/archive/v/AAfXfqRYyLnDFtskmLRi

Ответ 1

Хороший вопрос:-)! Я прочитал хороший ответ где-то, к сожалению, не могу найти это снова.

В основном диапазоны trie бывают быстрее. Здесь - одно объяснение. С помощью функции precisionStep вы определяете, насколько ваш индекс может расти, чтобы получить преимущества по производительности. Чтобы процитировать ссылку, которую вы имеете в виду:

"Что еще более важно, это не зависит от размера индекса, а вместо него выбрана точность".

"единственные недостатки TrieRange - это немного большие размеры индекса, поскольку дополнительные термины индексируются"

Ответ 2

Поля 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, 1275), поскольку 125x представляет собой предварительно вычисленное агрегирование 1250 - 1259. Если бы я использовал шаг точности, превышающий 1, запрос вернется к извлечению всех 25 отдельных записей.

Примечание: В действительности шаг точности относится к количеству битов, обрезанных для каждого токена. Если бы вы записывали свои цифры в шестнадцатеричном виде, то шаг точности 4 обрезал бы одну шестую цифру для каждого токена. Точный шаг 8 будет обрезать две шестнадцатеричные цифры.

Ответ 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, который будет использовать значение во время разбора потока токенов. Возможно, стоит поближе рассмотреть. Это, по-видимому, касается детализации и, вероятно, является компромиссом между размером индекса и скоростью.