solr: многозначные диапазоны дат (время работы - PullRequest
5 голосов
/ 26 сентября 2011

Рассмотрим бар, который может иметь несколько часов работы, в зависимости от дня недели (+ некоторые особые дни, когда он может быть закрыт) * ​​1001 *

Я хочу иметь возможность просматривать все открытые в данный момент бары, которые будут открыты, скажем, в течение 3 часов. (или быть в состоянии спросить: «открыто 18-10-2011 с 7 до (как минимум) 10)

Лучшее, что я считаю, это иметь «открытый, закрытый» кортеж для каждой даты (другие предложения приветствуются)

Без, насколько мне известно?, Типа поля, который объединяет часы открытия / закрытия в 1 поле, я могу наивно (но ошибочно) определить эту структуру, используя 2 поля: «открытое» и «закрытое», которые должны быть многозначное.

Теперь индексируйте их как:

open: 2011-11-08:1800 - close: 2011-11-09:0300
open: 2011-11-09:1700 - close: 2011-11-10:0500
open: 2011-11-10:1700 - close: 2011-11-11:0300

И запросы будут иметь вид:

open < now && close > now+3h

Но так как нет никакого способа указать, что 'open' и 'close' связаны попарно, я получу много ложных срабатываний, например, вышеупомянутый документ будет возвращен для:

open < 2011-11-09:0100 && close > 2011-11-09:0600

потому что НЕКОТОРЫЙ opendate предшествует 2011-11-09:0100 (т.е.: 2011-11-08:1800), а НЕКОТОРЫЕ закрытые - после 2011-11-09:0600 (например: 2011-11-11:0300), но эти даты открытия и закрытия не связаны попарно.

Я думал о совершенно другом подходе с использованием динамических полей Solr, в котором каждая дата открытия и закрытия получает свое собственное динамическое поле, например:

  • _date_2011-11-09_open: 1800
  • _date_2011-11-09_close: 0300
  • _дата_2011-11-09_открыто: 1700
  • _date_2011-11-10_close: 0500
  • _date_2011-11-10_open: 1700
  • _date_2011-11-11_close: 0300

Затем клиент должен знать дату запроса и, следовательно, правильные поля для запроса. Это решило бы проблему, так как startdate / enddate не связаны ни попарно, но я боюсь, что это может быть большой проблемой с точки зрения производительности (особенно потребление памяти кешем Lucene)

Таким образом, я не нашел удовлетворительного решения. Любая помощь высоко ценится.

Ответы [ 2 ]

2 голосов
/ 27 сентября 2011

Сохраняя гранулярность на барах, как я хочу (вместо BarsxDate), можно использовать экспериментальную реализацию Lucene Spatial Playground.

Вариант использования + общее решение здесь: https://issues.apache.org/jira/browse/SOLR-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=comment-13115244#comment-13115244

0 голосов
/ 26 сентября 2011

Первый вопрос - у вас действительно есть время для встреч? не дни недели? но оставляя это в стороне (это не меняет ответ ни в каком важном смысле), вам нужно создать документ для каждой комбинации столбца / даты. В каждом из этих документов вам понадобятся все поля, которые вы планируете искать; может быть, это включает местоположение, название бара и т. д. Таким образом, эти поля будут денормализованы (дублированы во многих связанных документах).

Таким образом, вы можете выполнить описанный вами запрос и получить точные результаты.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...