2009-05-06 3 views
4

Мне просто интересно, можем ли мы достичь некоторых возможностей РСУБД в lucene.Использование Lucene как реляционной базы данных

Пример: 1) У меня есть 10 000 проектных документов (pdf-файлов), которые необходимо проиндексировать с их содержимым, чтобы сделать их доступными для поиска. 2) Каждый документ относится к ОДНОМУ ПРОЕКТУ. Проект может содержать такие данные, как название проекта, номер, дата начала, дата окончания, местоположение, тип и т. Д.

Я должен искать в содержимом pdf-файлов для данного ключевого слова, но при отображении результатов я хочу отображать метаданные проекта, как указано в пункте (2).

Моя идея - связать поле под названием projectId с каждым файлом PDF при индексировании. Как только мы получим это, мы снова начнем поиск поиска для получения метаданных проекта.

Таким образом, мы могли бы избежать дублирования данных. Кроме того, если мы хотим обновить метаданные проекта, мы закончим обновление только на одном месте. В противном случае, если мы сохраним эти метаданные со всеми индексами pdf douce, мы закончим обновление всех документов, чего я не ищу.

сообщите пожалуйста.

+0

Вы пытаетесь избежать репликации, чтобы сократить объем пространства, занимаемого дублирующимися данными? Или вы пытаетесь избежать логистики для синхронизации двух систем? –

ответ

1

Если я вас правильно понимаю, у вас есть два вопроса:

  1. Могу ли я хранить идентификатор проекта в Lucene и использовать его для дальнейших поисков? Да, ты можешь. Это обычная практика.
  2. Могу ли я использовать этот идентификатор проекта для поиска Lucene для метаданных проекта? Да, ты можешь. Я не знаю, хорошая ли это идея. Это зависит от частоты ваших обновлений метаданных и вашего шаблона доступа. Если метаданные относительно статичны, и вы получаете доступ к ней только по id, Lucene может быть хорошим местом для ее хранения. В противном случае вы можете использовать идентификатор проекта в качестве первичного ключа в таблице базы данных, что может быть лучше подходит.
+0

hi, все индексы были бы только с lucene. связи с базой данных не будет. но структура люцен будет такой. означает 1) индекс: directory1 будет иметь индексы для документов с идентификатором продукта 2) Индекс: directory2 будет иметь индексы для продуктов, содержащих метаданные идентификатор продукта основная идея этого заключается в уменьшении размера индекса Lucene. означает, что каждый из этих 10 000 документов будет иметь метаданные продукта, что является повторением данных для этого, я хотел бы сделать отдельный индекс метаданных одного продукта, который будет вызван для использования идентификатора продукта там в индексе документа. –

+0

Изобразительное. Вы можете поддерживать запросы типа «дать мне все документы с идентификатором продукта nnn» или «дать мне метаданные для идентификаторов продуктов aaa, bbb». У вас даже может быть двухэтапный запрос, который означает «дать мне все метаданные для продуктов, относящихся к этим документам». Это менее гибко, чем СУБД, но это кажется достаточным для вашего варианта использования. Если вам нужны запросы диапазона, вам может потребоваться заполнить ваши идентификаторы нулями. –

1

Звучит как совершенно хорошо. Единственное ограничение, которое у вас есть (путем хранения ссылки на проект в Lucene, а не на самих данных проекта) заключается в том, что вы не сможете одновременно запрашивать текст документа и метаданные проекта. Например, "documentText: foo ИЛИ имя_проекта: bar". Если у вас нет такого требования, похоже, что хранить идентификатор в Lucene, который ссылается на строку базы данных, - это то, что нужно сделать.

0

Я не уверен в вашей общей настройке, но, возможно, Hibernate Search для вас. Это позволит вам объединить преимущества реляционной базы данных с мощью полнотекстового поискового движка, такого как Lucene. Метаданные могут жить в базе данных, возможно, вместе с оригинальными документами PDF, в то время как документы Lucene содержат только доступные для поиска данные.

1

Это определенно возможно. Но всегда помните о том, что вы используете Lucene для чего-то, для чего он не предназначен. В общем, Lucene предназначена для полнотекстового поиска, а не для отображения реляционного контента. Таким образом, чем сложнее ваша система, тем ваш реляционный контент становится, тем больше вы увидите снижение производительности.

В частности, есть несколько областей, чтобы держать закрыть глаза на:

  • Запоминание значение каждого поля в индексе снизится производительность. Если вас не слишком интересуют результаты поиска по второму запросу или если ваш индекс относительно невелик, это может не быть проблемой.
  • Кроме того, имейте в виду, что если вы не используете алгоритм ранжирования по умолчанию, а ваш пользовательский алгоритм требует информации о проекте, чтобы рассчитать оценку для каждого документа, это будет иметь огромное влияние на производительность поиска, поскольку Что ж.

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

Поскольку ваш проект продолжает расти, вы также можете проверить Solr, также разработанный Apache, который предоставляет некоторые дополнительные функции, такие как многогранный поиск.

1

Вы можете использовать Lucene таким образом;

Плюсы:

Полнотекстовый поиск легко осуществить, что это не так в РСУБД.

Минусы:

ссылочной целостности: вы получаете его бесплатно в РСУБД для, но в Lucene, вы должны реализовать ее самостоятельно.

+0

Я тоже не знаком с Lucene, но по http://stackoverflow.com/questions/1296709/getting-the-doc-id-in-lucene/1296943#1296943 кажется, что «document id» является внешним ключом также является проблемой, о которой должен заботиться пользователь. –

+0

Согласитесь: проблема ссылочной целостности является проблемой. – pvoosten