Вопрос по xml, pdf – Лучшие практики для поиска в архиве тысяч документов (PDF и / или XML)

43

Пересмотр зашедшего в тупик проекта и поиск советов по модернизации тысяч «старых» документы и сделать их доступными через Интернет.

Документы существуют в разных форматах, некоторые устарели :(.doc, PageMaker, распечатка (OCR),PDF, так далее.). Имеются средства для переноса документов в «современные». формат, и многие из бумажных копий уже были распознаны в PDF - мы изначально предполагали, что PDF будет окончательным форматом, но мы открыты для предложений (XML?).

После того, как все документы в едином формате, мы хотели бы сделать их содержимое доступным иsearchable via a web interface, Нам нужна гибкость, позволяющая возвращать только те части (страницы?) Всего документа, в которых поиск "ударил". найден (я полагаю, что Lucene /asticsearch делает это возможным?!?) Может ли это быть более гибким, если весь контент был XML? Если да, то как / где хранить XML? Прямо в базе данных или как отдельные файлы в файловой системе? Что насчет встроенных изображений / графиков в документах?

Любопытно, как другие могут подойти к этому. Там нет "неправильно" ответ Я просто ищу как можно больше информации, чтобы помочь нам продолжить.

Спасибо за любой совет.

Ваш Ответ

3   ответа
2

веснушка или жеRSolr или аналогичный, он обрабатывает большинство основных форматов документов. Они используют Solr / Lucene.

Файл - это файл, но мы хотели бы "обслуживать" только части полного документа за один раз. Таким образом, я полагаю, мы могли бы разбить каждый PDF-файл на сотни небольших PDF-файлов, которые станут громоздкими. Хотите знать, может ли XML сделать это проще в течение длительного времени?!? Возможно нет. Meltemi
плюсы и минусы минусы к PDF ov, er XML в этом случае? На данном этапе у нас есть возможность пойти в любую сторону. Я думаю, что PDF может быть проще для создания, но, возможно, труднее поддерживать & amp; & Quot; служить & Quot;?!? Не знаю. ищу совет. Meltemi
@ D.Newton - «тонны решений». хорошо, поэтому я задаю вопросы. Я ищу идеи. не пытаясь выбрать стороны. что касается "требований" они привязаны к тому, что возможно, сложность & amp; Стоимость. По сути, все, что я ЗНАЮ, - это то, что мы хотели бы, чтобы пользователи могли запрашивать все эти отчеты, и если есть "хит". настоящее "некоторые" часть документа, которая включает в себя «хит». и оттуда, я полагаю, мы хотели бы, чтобы пользователь мог продолжать пролистывать документ. Но не скачать все это. Надеюсь, что имеет смысл?!? Meltemi
@ Meltemi полностью зависит; не зная точных требований, трудно сказать. XML-базы данных как-то упали. Контент все еще должен быть отформатирован / преобразован, что может быть настолько простым или сложным, насколько вам нужно. Преобразование из исходного источника в XML, опять же в зависимости от ваших потребностей, может быть тривиальным или практически невозможным. Может быть лучше использовать решение для больших данных и полностью удалять файлы на уровне приложения - строка hBase может иметь миллионы столбцов, каждый из которых содержит абзац или что-то еще, каждая строка представляет собой один документ. Тонны решений.
@Meltemi Я не понимаю, как PDF будет сложнее обслуживать; файл есть файл. XML-файлы должны быть отформатированы, и вам необходимо выполнить преобразование между всеми форматами в xml.
2

которое индексирует и ищет документы в формате 70k + PDF. Я обнаружил, что необходимо вытащить простой текст из PDF-файлов, сохранить содержимое в SQL и проиндексировать таблицу SQL с помощью Lucene. В противном случае производительность была ужасной.

Какая польза от хранения контента в БД? Разве не было бы проще просто извлечь содержимое (при условии, что вы просто не использовали Solr и пропустить ручную обработку), проиндексировать его и выбросить текстовое содержимое?
Хорошо ... Я должен был вернуться и посмотреть на код. Вот что я делаю. Прежде всего, я должен сказать, у нас есть отдельный сервер индексирования, который обрабатывает только эту функцию. Вот процесс: 1) извлекать текст из PDF-файлов на контент-сервере 2) сохранять текст в .txt файлах, используя аналогичные имена каталогов / файлов. 3) индексировать текстовые файлы. После поиска мы можем сопоставить результаты с исходными PDF-файлами на основе путей к файлам / именования
Есть две причины, по которым мы сделали это таким образом. Во-первых, общее время индексации было быстрее. Во-вторых, в базе данных есть связанные данные, которые соответствуют каждому документу, таким образом, было проще построить полный индекс таким образом.
Я не вижу здесь никакой пользы от использования реляционных БД. @ Дейв, одно исправление: вы не выбрасываете исходный текст, вы используете поисковую систему (Solr, ES, ...), чтобы индексировать и сохранять его. Затем в результатах поиска вы просто показываете ссылку на оригинальный файл.
111

ElasticSearchНо давайте разберем проблему и поговорим о том, как ее реализовать:

Есть несколько частей к этому:

Extracting the text from your docs to make them indexable Making this text available as full text search Returning highlighted snippets of the doc Knowing where in the doc those snippets are found to allow for paging Return the full doc

Что может предоставить ElasticSearch:

ElasticSearch (like Solr) uses Tika to extract text and metadata from a wide variety of doc formats It, pretty obviously, provides powerful full text search. It can be configured to analyse each doc in the appropriate language with, stemming, boosting the relevance of certain fields (eg title more important than content), ngrams etc. ie standard Lucene stuff It can return highlighted snippets for each search result It DOESN'T know where those snippets occur in your doc It can store the original doc as an attachment, or it can store and return the extracted text. But it'll return the whole doc, not a page.

Вы можете просто отправить весь документ в ElasticSearch в виде вложения, и вы получите полнотекстовый поиск. Но точки соприкосновения (4) и (5) выше: знание того, где вы находитесь в документе, и возвращение частей документа.

Хранения отдельных страниц, вероятно, достаточно для ваших целей «где я» (хотя вы могли бы также перейти на уровень абзаца), но вы хотите, чтобы они были сгруппированы таким образом, чтобы документ возвращался в результатах поиска, даже если ключевые слова поиска появляются на разных страницах.

Сначала часть индексации: хранение ваших документов в ElasticSearch:

Use Tika (or whatever you're comfortable with) to extract the text from each doc. Leave it as plain text, or as HTML to preserve some formatting. (forget about XML, no need for it). Also extract the metadata for each doc: title, authors, chapters, language, dates etc Store the original doc in your filesystem, and record the path so that you can serve it later In ElasticSearch, index a "doc" doc which contains all of the metadata, and possibly the list of chapters

Index each page as a "page" doc, which contains:

A parent field which contains the ID of the "doc" doc (see "Parent-child relationship" below) The text The page number Maybe the chapter title or number Any metadata which you want to be searchable

Теперь для поиска. Как вы это сделаете, зависит от того, как вы хотите представить свои результаты - по странице или сгруппированы по документу.

Результаты на странице легко. Этот запрос возвращает список соответствующих страниц (каждая страница возвращается полностью), а также список выделенных фрагментов со страницы:

curl -XGET 'http://127.0.0.1:9200/my_index/page/_search?pretty=1'  -d '
{
   "query" : {
      "text" : {
         "text" : "interesting keywords"
      }
   },
   "highlight" : {
      "fields" : {
         "text" : {}
      }
   }
}
'

Отображение результатов, сгруппированных по & quot; doc & quot; с основными моментами из текста немного сложнее. Это нельзя сделать одним запросом, но небольшая группировка на стороне клиента поможет вам в этом. Один подход может быть:

Шаг 1: сделатьтоп-дети-запрос чтобы найти родителя («документ»), чьи дочерние элементы («страница») лучше всего соответствуют запросу:

curl -XGET 'http://127.0.0.1:9200/my_index/doc/_search?pretty=1'  -d '
{
   "query" : {
      "top_children" : {
         "query" : {
            "text" : {
               "text" : "interesting keywords"
            }
         },
         "score" : "sum",
         "type" : "page",
         "factor" : "5"
      }
   }
}

Шаг 2. Соберите «документ» Идентификаторы из вышеупомянутого запроса и введите новый запрос, чтобы получить фрагменты с соответствующей страницы & quot; quot; документы:

curl -XGET 'http://127.0.0.1:9200/my_index/page/_search?pretty=1'  -d '
{
   "query" : {
      "filtered" : {
         "query" : {
            "text" : {
               "text" : "interesting keywords"
            }
         },
         "filter" : {
            "terms" : {
               "doc_id" : [ 1,2,3],
            }
         }
      }
   },
   "highlight" : {
      "fields" : {
         "text" : {}
      }
   }
}
'

Шаг 3. В вашем приложении сгруппируйте результаты вышеупомянутого запроса по документу и отобразите их.

С результатами поиска по второму запросу у вас уже есть полный текст страницы, который вы можете отобразить. Чтобы перейти на следующую страницу, вы можете просто найти ее:

curl -XGET 'http://127.0.0.1:9200/my_index/page/_search?pretty=1'  -d '
{
   "query" : {
      "constant_score" : {
         "filter" : {
            "and" : [
               {
                  "term" : {
                     "doc_id" : 1
                  }
               },
               {
                  "term" : {
                     "page" : 2
                  }
               }
            ]
         }
      }
   },
   "size" : 1
}
'

Или, в качестве альтернативы, укажите «страницу» Документы, состоящие из$doc_id _ $page_num (например, 123_2), тогда вы можете просто получить эту страницу:

curl -XGET 'http://127.0.0.1:9200/my_index/page/123_2

Parent-child relationship:

Обычно в ES (и большинстве решений NoSQL) каждый документ / объект независим - нет реальных отношений. Путем установления отношений между родителем и ребенком между "doc" и «page», ElasticSearch гарантирует, что дочерние документы (то есть «страница») хранятся в том же сегменте, что и родительский документ («документ»).

Это позволяет вам запуститьтоп-дети-запрос который найдет лучшее соответствие & quot; документу & quot; на основе содержания "страниц".

Если вы разделите страницу, то вы также не сможете найти фразы, разбитые на несколько страниц, не так ли?
Хорошо, я скажу это:"DrTech for President!" ;-) Фантастический ответ! Жаль, что я не мог голосовать больше. Спасибо! Meltemi
Вы сами не знаете, как выполнить индексацию каждой «страницы». PDF? Meltemi
:) Забавно, меня зовут Клинтон, в конце концов :)
Инструменты Попплераpoppler.freedesktop.org доступно по умолчанию на большинстве дистрибутивов Linux очень быстро и очень хорошо.

Похожие вопросы