Solr поле даты tdate против даты?

Question

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

Схема .xml утверждает, что «Для запросов с более быстрым диапазоном рассмотрите тип tdate» и «Поле даты на основе Trie для более быстрых запросов диапазона дат и фасетирования даты. ' Достаточно справедливо ... но что это за PrecisionStep = "6"? я должен изменить это? это изменит способ, которым я создал бы запрос в случае, если я использую tdate? В чем реальное преимущество или что делает Solr, что делает его лучше?

P.S без всякой удачи прошел google, руководство по Solr, solr wiki и документы по 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 ускоряют запросы диапазона, предварительно вычисляя определенные результаты диапазона и сохраняя их как одну запись в индексе. Для ясности, мой пример будет использовать целые числа в десятичной базе. Та же концепция применима ко всем типам дерева. Это включает в себя даты, поскольку дата может быть представлена ​​в виде количества секунд, скажем, с 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) и объединить результаты поиска. Имея три поля (и шаг точности 1), мы можем выбрать 8 записей (125x, 126x, 1270, 1271, 1272, 1273, 1274, 1275), поскольку 125x - это предварительно вычисленная агрегация 1250 - 1259. Если бы я использовал шаг точности больше 1, запрос вернулся бы к извлечению всех 25 отдельных записей.

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

Answer 2

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

В основном, три диапазона быстрее. Здесь - это одно объяснение. С помощью PrecisionStep вы настраиваете, насколько может расти ваш индекс, чтобы получить выигрыш в производительности. Цитировать по ссылке, на которую вы ссылаетесь:

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

и

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

Answer 3

Лучше всего просто взглянуть на исходный код. Некоторые вещи для Solr плохо документированы, и самый быстрый способ получить надежный ответ - просто взглянуть на код. Если вы еще не были в коде, это тоже в ваших интересах. По крайней мере, в долгосрочной перспективе.

Вот ссылка на завод TrieTokenizer.

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. Вы можете копать дальше.

РЕДАКТИРОВАТЬ: Я вырыл немного дальше для вас. Он передается непосредственно классу Lucerne NumericTokenStream, который будет использовать это значение при разборе потока токенов. Вероятно, стоит поближе изучить. Кажется, он имеет дело с гранулярностью и, вероятно, является компромиссом между размером индекса и скоростью.