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

Question

[datahub4]

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

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

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

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

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

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

Comments

[Владимир Коротенко]

Кстати в порядке эксперимента попробуйте SharePoint, для его поисковика нагрузка вполне по силам.

https://cann0nf0dder.wordpress.com/2016/09/07/buil...

Answer 1

[d'Ivan]

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.
Такой объем данных будет нелегко обработать. Будет много мороки с инфраструктурой и эксплуатацией ПО.

Comments

[al_gon]

плюсую

Answer 2

[Frozen Coder]

За таким поиском вам в elasticSearch, там и полнотекстовый и Highlighting есть. Масштабируется относительно легко.

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

Но правда жрать ресурсы всё это добро будет нормально так :(

Answer 3

[anikavoi]

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

Answer 4

[Cheypnow]

Elastic search / Solr

Answer 5

[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.

Comments

[datahub4]

Почитал больше про elastic и solr
Немаловажно что есть готовый инструмент чтобы данные из пдф брать, остальное проверим на практике.

Answer 6

[Алексей Карташов]

А почему никто не упомянул Sphinx?

Comments

[Александр Аксентьев]

Потому что он скорее мёртв чем жив к сожалению.

Статей, мануалов толковых мало, апдейтов нет и т.д.

[Алексей Карташов]

Ну Аксёнов каждый год выступает на HighLoad'е с докладами по Sphinx'у, митапы вон какие-то проводят (судя по официальному сайту). С толковыми мануалами на русском - да, есть такая проблема. Но документация (пусть и на английском) - в наличии, релизы с фиксами и улучшениями (после выхода третьей версии) выходят стабильно.
Да и в полнотекстовом поиске уже давно всё изобретено - выдумывать что-то новое здесь сложно)
А sphinx вполне себе шустрый движок, старается выдавать максимальную производительность, по потребляемым ресурсам - эластику точно фору даёт.
Вот за горизонтальное масштабирование судить не берусь, может быть эластик в этом плане будет выигрышнее.

[Dimonchik]

ну, Аксенов - надо признать честно - перешел в Авито на фуллтайм

но

Сфинкс подхватили manticoresearch , с бОльшим числом мануалов, но, увы, тоже для тех кто в теме
хотя(!) их штука работает из коробки, на надо конфиг писать, индексер запускать и все такое

а не упомянули, потому что у "никто" массивы данных по 50к )), там не то что Эластик на VPS справится, там Эксель справится

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

плюс, конечно, у Эластика много создано для удобства програмера

где Сфинкс, там и Reindexer, при прочих равных - сопоставимо по затратам на поддержку, Го-прогеров потихоньку становится больше

Answer 7

[Владимир Коротенко]

Рекомендую элластик, впрочем мы использовали Lucene.Net это его основа. Впрочем родные движки FTS в постгре, оракле и mssql то же неплохие.

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

https://habr.com/ru/post/280488/

Comments

[Сергей Горностаев]

родные движки FTS в постгре, оракле и mssql то же неплохие.

С производительностью и горизонтальным масштабированием у них всё очень плохо, в сравнении с эластиком.

Answer 8

[xmoonlight]

Рекомендую сделать это руками без применения олдскульных инструментов (Эластик, Монго, Постгр, Касандру). Определитесь с тем, какие у вас данные, затем - как их связать.

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

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

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

Все требования исполняются на 100%.

Comments

[bozuriciyu]

Лечитесь, уважаемый! Что ни коммент то новые уровни шизофрении.

[xmoonlight]

bozuriciyu, Неаргументированность вместе с агрессией - первый признак низкого образования.

Answer 9

[Алексей Приказчиков]

Не знаю, я бы существующие проиндексировал, а новые или изменённые индексировал в процессе добавления (изменения). Т.е. выдёргивал текст и уже по тексту по базе гонял Снипиксом. Как в поисковых системах. Быстрее в любом случае искать по тексту файла и получать список ссылок, чем поиском по файлам. Да данные будут избыточны, но скорость будет ощутимо выше. Потому как там дальше и индексы, и прочее.

Answer 10

[akimdi]

его уже пробовали?

Answer 11

[Gnusi]

ArangoSearch в ArangoDB пробовали?