2011-05-25 3 views
10

У меня есть запрос, который делает ILIKE в 11 строковых или текстовых полях таблицы, которая не большая (500 000), но для ILIKE явно слишком большая, поисковый запрос занимает около 20 секунд. База данных - postgres 8.4Hibernate Search, Lucene или любая другая альтернатива?

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

Что пришло на ум:

  1. Я сделал дополнительный столбец TVector, собранный из всех столбцов, которые должны быть найдены, и создал полнотекстовый индекс на нем. Полнотекстовый поиск был довольно быстрым. Но ... Я не могу отобразить этот тип TVECTOR в моем .hbms. Таким образом, эта идея отпала (в любом случае я оттолкнул ее скорее как временное решение).

  2. Hibernate поиск. (Слышал об этом в первый раз сегодня). Кажется, это обещание, но мне нужно испытать это, потому что я не хочу входить в новый API, возможно, не самый простой, для чего-то, что можно было бы сделать проще.

  3. Lucene

В любом случае, теперь это случилось с этой таблицей, но я хотел бы, чтобы решение было более универсальными и применяются для будущих дел, связанных с полнотекстовым поиском.

Все советы оценены!

Thanx

ответ

12

Я бы настоятельно рекомендовал Hibernate Search, который обеспечивает очень простой в использовании мост между Hibernate и Lucene. Помните, вы будете использовать оба здесь. Вы просто аннотируете свойства своих классов домена, которые вы хотите найти. Затем, когда вы обновляете/вставляете/удаляете объект, который включен для поиска, Hibernate Search просто обновляет соответствующие индексы. Это произойдет только в том случае, если транзакция, в которой происходят изменения базы данных, была зафиксирована, то есть если она будет откат, индексы не будут разбиты.

Так, чтобы ответить на ваши вопросы:

  1. Да, вы можете индексировать определенные столбцы по конкретным таблицам. У вас также есть возможность Tokenize содержимого поля, чтобы вы могли соответствовать по частям поля.

  2. Это совсем не сложно, вы просто определяете, какие свойства вы хотите искать. Сообщите Hibernate, где хранить свои индексы. А затем можно использовать интерфейсы EntityManager/Session для загрузки объектов, которые вы искали.

+0

thanx для объяснений, еще один короткий вопрос. Я хочу, чтобы иметь возможность искать несколько строковых полей. Имеет ли смысл хранить все остальные поля в индексе, но не сделать поиск, а затем, когда я ударил, я получаю объект оттуда или должен просто получить IDS и перейти в базу данных, чтобы получить их ? – Julia

+0

@Julia Вы должны индексировать только те поля, которые вы хотите найти. Вы указываете Hibernate Search, что такое @DocumentId (также @Id) индексированного объекта. Затем Hibernate будет использовать этот идентификатор, чтобы получить сущность из базы данных (или кеша сеанса), не беспокоясь об этом. По сути, Hibernate Search принимает строку поиска и возвращает вам сущности домена, соответствующие этому поиску. Аккуратно? –

+0

аккуратно, спасибо! – Julia

0

Я рекомендую Compass. Это проект с открытым исходным кодом, построенный на вершине Lucene, который предоставляет более простой API (чем Lucene). Он прекрасно сочетается со многими распространенными библиотеками Java и такими фреймворками, как Spring и Hibernate.

0

Я использовал Lucene в прошлом для индексации таблиц базы данных. Решение отлично работает, но помните, что вам нужно поддерживать индекс. Либо вы обновляете индекс каждый раз, когда ваши объекты сохраняются, либо у вас есть индексный индекс, который выгружает таблицы базы данных в вашем индексе Lucene.

Считаете ли вы, что Solr? Он построен поверх Lucene и предлагает автоматическую индексацию из базы данных и API Rest.

+0

thanx. мы уже используем lucene для индексации документов, поэтому я лучше поймаю одну и ту же библиотеку. Как можно было бы с Lucene, например, я хочу индексировать некоторые отношения объектов? Должен ли я индексировать целые таблицы, или я мог бы делать определенные столбцы, которые мне нужны из основной таблицы и некоторых ее отношений? – Julia

+0

То, как я это делал, заключалось в том, чтобы использовать SELECT-запросы с помощью JOINS для создания «плоской» структуры моих данных, чтобы я мог запускать на них индекс. Это один из подходов. Вы также можете использовать хранимые процедуры, чтобы сгладить ваши данные в специальную таблицу, используемую для целей индексирования. –

0

Все проекты основаны на Lucene. Если вы хотите реализовать очень продвинутые функции, я советую вам напрямую использовать Lucene. Если нет, вы можете использовать Solr, который является мощным API поверх lucene, который может помочь вам индексировать и искать из БД.

+0

Мне не нужны слишком сложные функции, я думаю, но хотелось бы избежать использования новой библиотеки, которую мы пока не используем. Я не уверен, что понял, почему вы рекомендуете Solr - который в любом случае построен на lucene? Не могли бы вы немного уточнить, пожалуйста? Спасибо вам!!! – Julia

+0

Я приведу вам пример: вы должны сделать http-звонки на веб-сервер. В java есть библиотека сокетов, которая помогает вам это сделать, но лучше: apache commons http client. Это именно то, что поставляется со встроенными библиотеками, которые реализуют протокол. То же самое для Solr, который имеет встроенный API для управления индексами, легкий полнотекстовый поиск с легкой интеграцией баз данных и предназначен для запуска контейнера сервлетов. –

6

Поскольку вы уже используете Hibernate и Lucene, Hibernate Search - отличный выбор.

В первую очередь, поиск Hibernate Search - это механизм обновления индексов Lucene при изменении данных и возможность максимизировать то, что вы уже знаете о Hibernate, чтобы упростить поиск по индексам Lucene.

Вы сможете указать, какие конкретные поля в каждом объекте вы хотите индексировать, а также добавлять по мере необходимости несколько типов индексов (например, стебель и полный текст). Вы также сможете управлять индексом для ассоциаций, чтобы вы могли делать довольно сложные запросы через Search/Lucene.

Я нашел, что лучше всего использовать Hibernate. Поиск текстовых поисков, но вернуться к простому Hibernate для более традиционного поиска и для гидратации сложных графиков объектов для отображения результатов.

0

Год назад я бы рекомендовал компас. Было хорошо, что он делает, и технически все еще счастливо работает в приложении, которое я разработал и поддерживаю.

Однако на Compass больше нет разработок, при этом усилия переключились на ElasticSearch. С веб-сайта этого проекта я не могу полностью определить, готов ли он к Большому времени или даже на самом деле жив.

Итак, я перехожу в Hibernate Search, который не дает мне такого хорошего ощущения, но миграция все еще находится на начальных этапах, поэтому я буду оставлять суждение еще долго.

 Смежные вопросы

  • Нет связанных вопросов^_^