Apache Lucene: создание индекса между строками и интеллектуальный поиск

Question

Моя проблема заключается в следующем: допустим, у меня есть три файла.A, B и C. Каждый из этих файлов содержит 100-150M строк (по одной на строку).Каждая строка имеет формат иерархического пути, например / e / d / f.Например:

File A (RTL):
/arbiter/par0/unit1/sigA
/arbiter/par0/unit1/sigB
...
/arbiter/par0/unit2/sigA

File B (SCH)
/arbiter_sch/par0/unit1/sigA
/arbiter_sch/par0/unit1/sigB
...
/arbiter_sch/par0/unit2/sigA

File C (Layout)
/top/arbiter/par0/unit1/sigA
/top/arbiter/par0/unit1/sigB
...
/top/arbiter/par0/unit2/sigA

Мы можем представить файл A, соответствующий сигналам схемы на языке аппаратного моделирования.Файл B, соответствующий цепным сигналам в схематическом списке соединений.Файл C, соответствующий схемным сигналам в макете (для производства).

Теперь сигнал будет отображаться между файлом A <-> файлом B <-> файлом C. Например, в этом случае / арбитр /par0 / unit1 / sigA == / арбитр_sch / par0 / unit1 / sigA == / top / арбитр / par0 / unit1 / sigA.Конечно, эта ассоциация (эквивалентность) установлена ​​мной, и я не ожидаю, что средство сопоставления выяснит это для меня.

Теперь скажем, я даю '/ арбитр / par0 / unit1 / sigA'.В этом случае средство сопоставления должно вернуть прямое совпадение из файла A, поскольку оно найдено.Для файла B / C прямое совпадение невозможно.Таким образом, он должен возвращать наилучшие возможные совпадения (т. Е. Расстояние редактирования). Таким образом, в этом примере он может выдать / арбитр_sch / par0 / unit1 / sigA из файла B и / top / арбитр / par0 / unit1 / sigA из файла C.

Вместо полного поиска строки, я мог бы также дать что-то вроде * par0 * unit1 * sigA, и это должно дать мне все возможные совпадения из файла A / B / C.

Я ищуза решения и наткнулся на Apache Lucene.Однако я не совсем уверен, сработает ли это.Я просматриваю документы, чтобы получить представление.

Мои основные требования следующие:

1. Будет 3 текстовых файла с полным путем к сигналам.(Я могу изменить формат, чтобы сделать его более компактным, если это поможет быстрее построить индексатор).

2. Построение индекса должно быть достаточно быстрым (это займет несколько часов).Приведенные выше файлы являются статическими (без изменений).

3. Поиск должен быть всеобъемлющим.Это нормально, если требуется ~ 1 с / поиск, но сопоставление должно поддерживать прямое сопоставление, сопоставление с регулярным выражением и редактирование сопоставления расстояний.Основная проблема заключается в том, что каждый файл может иметь 100-150 миллионов сигналов.

Может кто-нибудь сказать мне, может ли Lucene легко разрешить такой случай использования?Как правильно построить индекс и выполнить быстрый / быстрый поиск?Я хотел бы написать некоторый проверочный код и проверить производительность.Спасибо.

Answer 1

Я думаю, исходя из ваших требований, лучшим решением будет PoC с заданным набором тестов.Исходя из этого, должна быть возможность оценить целевое время индексации, которое вы хотели бы достичь.Поскольку вы используете только статическую информацию, это проще, потому что вам не нужно заботиться о таких темах, как NRT (поиск почти в реальном времени).

Лично я никогда не использовал lucene для такого большого набора информации, но я думаю,lucene может справиться с этим.

Как бы я это сделал:

• Прочитайте учебные пособия и лучшие практики по lucene, индексации, поиску и поймите, как это работает
• Определить набор данных для индексации, скажем, 1000 строк для каждого файла
• Определить структуру документа lucene

это действительно важно, потому что на основании этого вы будете применять свои поиски.позаботьтесь о задачах анализатора, таких как токанизация, если необходимо и как.Если вам нужна полнотекстовая поисковая забота о TextField.

• Напишите код для простой индексации

Запустите небольшие тесты с индексацией и проверьте свой индекс с помощью Luke

• Введите код для простого поиска

Определите запросы и ожидаемые результаты.выполнять поиск и проверять результаты.

Попробуйте структурировать свой код.раздельное индексирование и поиск -> рефакторинг будет проще.