Что выбрать для полнотекстового поиска по большому объёму данных?

Доброго дня
Стоит такая амбициозная (для меня по крайней мере) задача

Есть ~50M PDF документов, средний размер каждого ~1MB, минимальный 10KB, максимальный 50MB.
Суммарный объём выходит под 50TB.
95% данных в документе это текст.
Нужно обеспечить полнотекстовый поиск по всему объёму данных, тоесть есть фраза - надо показать документы где она встречается и (опционально) показать снипеты, тоесть текстовое окружение где в документе нашлась фраза.

Добавление даных в базу происходит редко и оно некритично, тоесть его можно выполнять долго и с низким приоритетом. Удаление/изменение данных не случается вообще.

Требования к системе в порядке приоритета.
1 Возможность запустить это всё на как можно более дешёвом и доступном железе - это критично т.к. бюджет на инфраструктуру ограничен
2 Скорость поиска
3 Надёжность и отказоустойчивость
4 Лёгкость масштабирования

Самостоятельно почитал про Эластик, Монго, Постгр, Касандру и от этого ещё больше запутался.

Если у кого-то есть опыт в схожих задачах поделитесь идеей при помощи каких технологий это можно было бы реализовать.
Спасибо заранее всем откликнувшимся
  • Вопрос задан
  • 1644 просмотра
Решения вопроса 5
2ord
@2ord
продвинутый чайник
Sphinx/Manticore Search могут подойти и по экономичности и по объему данных.
Эластик скушает всю память и не подавится.

Добавлено
Есть и другие игроки.
Solr has been more oriented towards text search. Elasticsearch quickly carved out its niche, aiming for log analytics by creating the Elastic Stack

Apache Solr. SolrCloud - шардинг и репликация. Solr умеет анализировать (искать) различные документы.
Elasticsearch vs. Solr vs. Sphinx: Best Open Sourc...
Для извлечения текста и метаданных самостоятельно можно использовать фреймворк Apache Tika.
Apache Hadoop - для хранения PDF.
Такой объем данных будет нелегко обработать. Будет много мороки с инфраструктурой и эксплуатацией ПО.
Ответ написан
@frozen_coder
Java-developer
За таким поиском вам в elasticSearch, там и полнотекстовый и Highlighting есть. Масштабируется относительно легко.

Сами документы можно положить в монгу - она тоже масштабируется неплохо. Т.е. эластик ищет, возвращает вам idшники документов, вы по ним достаёте сами документы из монги.

Но правда жрать ресурсы всё это добро будет нормально так :(
Ответ написан
@anikavoi
На опыте нашей фирмы, подобная задача решается в Solr или Эластике. Постгри не насилуйте ни удовольствия от процесса ни результата не будет.
Ответ написан
@bozuriciyu
Apache Tika

The Apache Tika™ toolkit detects and extracts metadata and text from over a thousand different file types (such as PPT, XLS, and PDF). All of these file types can be parsed through a single interface, making Tika useful for search engine indexing, content analysis, translation, and much more.


Apache Solr

Here are the three most common ways of loading data into a Solr index:

Using the Solr Cell framework built on Apache Tika for ingesting binary files or structured files such as Office, Word, PDF, and other proprietary formats.

Ответ написан
Пригласить эксперта
Ответы на вопрос 6
А почему никто не упомянул Sphinx?
Ответ написан
firedragon
@firedragon
Senior .NET developer
Рекомендую элластик, впрочем мы использовали Lucene.Net это его основа. Впрочем родные движки FTS в постгре, оракле и mssql то же неплохие.

Основной затык это морфология, а точнее словари, во всяком случае в случае кирилицы и немецкого.

https://habr.com/ru/post/280488/
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Рекомендую сделать это руками без применения олдскульных инструментов (Эластик, Монго, Постгр, Касандру). Определитесь с тем, какие у вас данные, затем - как их связать.

Обычно, одна нода ("узел") - это один слог (любого слова).
Дальше - стройте граф, проходя по тексту: занося слоги и ставя связи (слева-справа: id-шники соседних "узлов"), и отдельно - локации: id-узла, id-локации (линк, файл, документ, URL и т.п.).

Поиск - путь по нодам даст сразу все локации. (это мнгновенно, т.к. всё по ID происходит)

Требования к системе в порядке приоритета.
1 Возможность запустить это всё на как можно более дешёвом и досутпном железе - это критично т.к. бюджет на инфраструктуту ограничен
2 Скорость поиска
3 Надёжность и отказоустойчивость
4 Лёгкость масштабирования
Все требования исполняются на 100%.
Ответ написан
alexprik07
@alexprik07
Программист, верстальщик.
Не знаю, я бы существующие проиндексировал, а новые или изменённые индексировал в процессе добавления (изменения). Т.е. выдёргивал текст и уже по тексту по базе гонял Снипиксом. Как в поисковых системах. Быстрее в любом случае искать по тексту файла и получать список ссылок, чем поиском по файлам. Да данные будут избыточны, но скорость будет ощутимо выше. Потому как там дальше и индексы, и прочее.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы