ReSQL.ru
     
powered by simpleCommunicator - 2.0.56     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / Apache Lucene и поиск в диапазоне дат
4 сообщений из 4, страница 1 из 1
Apache Lucene и поиск в диапазоне дат
    #39677142
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Привет коллеги.

Вопрос

Поддерживает ли Apache Lucene поиск документов в диапазоне дат или тайм-стампов?

Детали
 

Есть документ вида:

Код: java
1.
2.
3.
4.
5.
6.
public class Message {
    private String id; // GUID
    private java.sql.Timestamp timestamp; // Event timestamp
    private String messageText; // Content. Around 170 characters
    ....
}



Многоточием отмечены другие атрибуты и методы которые не суть важны в моем вопросе.

Таких документов будет порядка 100 млн. Необходимо быстро их искать в диапазоне дат и по содержимому.
История хранения - примерно 3 года.

В форме пользователь будет указывать диапазон дат например:

Код: java
1.
from=2018-07-20 00:00:00, to=2018-07-21 00:00:00, messageText="Google"


...
Рейтинг: 0 / 0
20.07.2018, 22:38
| Ответить | Цитировать | Написать  
Apache Lucene и поиск в диапазоне дат
    #39677168
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
 
...
Fields
Lucene supports fielded data. When performing a search you can either specify a field, or use the default field. The field names and default field is implementation specific.
You can search any field by typing the field name followed by a colon ":" and then the term you are looking for.
...

Range Searches
Range Queries allow one to match documents whose field(s) values are between the lower and upper bound specified by the Range Query. Range Queries can be inclusive or exclusive of the upper and lower bounds. Sorting is done lexicographically.
mod_date:[20020101 TO 20030101]
...
?

P.S.
Как обычно - из документации .
...
Рейтинг: 0 / 0
21.07.2018, 00:36
| Ответить | Цитировать | Написать  
Apache Lucene и поиск в диапазоне дат
    #39677968
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Я так и сделал. Timestamp был преобразован в строку. И сохранен как текстовое поле. В лексикографическом порядке.

Макет.
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
ResultSet resultSet = st.executeQuery(sql);
        
        while(resultSet.next()) {
            String id          = resultSet.getString("id");
            String timestamp   = timestampToString(resultSet.getTimestamp("timestamp"));
            String messageText = resultSet.getString("message");

                org.apache.lucene.document.Document document = new Document();
                document.add(new StringField("id", id,     Field.Store.YES));
                document.add(new StringField("ts", timestamp, Field.Store.YES));
                document.add(new TextField("message", messageText, Field.Store.YES));
                writer.addDocument(document);
            
        }




Надеюсь что эта хрень работает.
Код: java
1.
mod_date:[20020101 TO 20030101]



А теперь мой главный вопрос. Селективность данного поиска (насколько мне позволяют судить мои знания)
должна базироваться на:

1) на поиске в первую очередь по интервалу дат. Напоминаю что в базе хранятся сведенья за 3 года. Пользователь
по юзкейсу будет в 90% искать текущий день. Или опционально неделю или месяц в прошлом. Это оставшиеся 10%
запрсов.

Тоесть в 90% случаев пользователь будет искать (3 года = 365 * 3 = 1095 days) примерно одну тысячную
от содержимого Lucene индекса. И если мы здесь не воспользуемся свойством разделения датасета на дни
то будем искать по 100 млн записям вместо 100 000 / 1000 = 100 замисей. Вот такая моя простая арифметика
как в книге Брюса Шнайера. Я готов допустить что я где-то ошибся. Плюс минус порядок. Но даже в таком
кейсе аппроксимация негативного случая лучше чем вообще незнание о том что этот случай где-то существует.

2) на текстовом поиске по содержимому messageText. Здесь я хочу сделать некоторые дополнения.
Нечеткий поиск. Стемминг. Языки. Всё это мне нефиг не нужно! Мне нужне 100% точный поиск
по совпадению. Из юзкейсов мне известно.

Месседж содержит текст в формате Fix-протокола (выдержка из Википедии).

Код: java
1.
8=FIX.4.2 | 9=178 | 35=D | 34=123123 | 49=BROKER11 | 56=PHLX | 52=20071123-05:30:00.000 | 11=ATOMNOCCC9990900 | 55=MSFT | 167=FUT | 54=1 | 38=15 | 40=2 | 44=15 | 59=0 | 10=128 |



Тоесть Анализатор нужно упростить до выделения номеров тегов и содержания.
(Здесь в скобках замечу что я не писал анализаторы. Стек достаточно сложен для понимания
того что именно надо перегружать для своей задачи. Я делал токенайзер хотя не уверен
в том что только токенайзер надо фиксить. Возможно следует где-то еще что-то добавить.)

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
public class SplitTokenizer extends CharTokenizer {
   
    @Override
    protected boolean isTokenChar(int i) {
        char c = (char)i;
        return c=='|' || c=='=';
    }
}



Пользователь будет лупить либо значение (value) тега либо ключ + значение.

Cases:
1)
Код: java
1.
PHLX


2)
Код: java
1.
56=PHLX



Теоретически пользователь будет лупить месседж целиком либо фрагмент месседжа. Тут я ничего
не готов придумать. Просто сохраняю new TextField(.... Store.Yes). На всякий случай надеясь
что полное сообщение тоже пригодится.

3)
Код: java
1.
49=BROKER11 | 56=PHLX | 52=20071123-05:30:00.000



Здесь порядок поиска очень важен т.к. если мы проигнорируем особенности временного распределения
месседжей по оси времени то получим обычный брут-форс всего что есть с довыборкой по фильтру.

По результатам. Моё поверхностное наблюдение за API а дает мне основания говорить что поле timestamp
не будет хранится как B+Tree. Скорее всего оно ляжет как атрибут. Это очень печально по причинам о которых
я писал в пункте (1). Впрочем бенчмарки еще не готовы.

Вобщем я к тому что чуда не жду. Скорость должна базироваться на предположениях относительно пути доступа.
И пресловутой o(n) как в умных книжках про алгоритмы. Но в данном случае ничто не говорит о хорошем o(n).

P.S.Надеюсь не сильно сложно описал.

От коллег жду рекомендаций по Анализатору и Токенайзеру а также по выключению нахер всех Fuzzy-поисков
и по поиску по более крупным фрагментам месседжей. Того кейса который не является (1) и (2).
...
Рейтинг: 0 / 0
23.07.2018, 22:14
| Ответить | Цитировать | Написать  
Apache Lucene и поиск в диапазоне дат
    #39686686
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Up. Вчера потратил n человеко-часов на изучение встраиваемых dbms
- berkeleydb
- rocksdb
- leveldb

Выводы отпишу чуть позже.
...
Рейтинг: 0 / 0
13.08.2018, 09:23
| Ответить | Цитировать | Написать  
4 сообщений из 4, страница 1 из 1
Форумы / Java [игнор отключен] [закрыт для гостей] / Apache Lucene и поиск в диапазоне дат
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=59&fpage=41&tid=2121853]:
 0ms
get settings:
 11ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 37ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 74ms
get tp. blocked users:
 2ms
others: 12ms
total:  174ms
созд. / загр.: 174ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]