Задать вопрос
@datahub4
базы-данных

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

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

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

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

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

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

Если у кого-то есть опыт в схожих задачах поделитесь идеей при помощи каких технологий это можно было бы реализовать.
Спасибо заранее всем откликнувшимся
  • Вопрос задан
  • 2069 просмотров
1 комментарий
Подписаться 16 Простой 1 комментарий
Решения вопроса 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.
Такой объем данных будет нелегко обработать. Будет много мороки с инфраструктурой и эксплуатацией ПО.
Ответ написан
1 комментарий
1 комментарий
@frozen_coder
Java-developer
За таким поиском вам в elasticSearch, там и полнотекстовый и Highlighting есть. Масштабируется относительно легко.

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

Но правда жрать ресурсы всё это добро будет нормально так :(
Ответ написан
Комментировать
Комментировать
@anikavoi
На опыте нашей фирмы, подобная задача решается в Solr или Эластике. Постгри не насилуйте ни удовольствия от процесса ни результата не будет.
Ответ написан
Комментировать
Комментировать
@Cheypnow
Elastic search / 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.

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

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

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

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

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

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

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

Войти через центр авторизации
Похожие вопросы
Вакансии с Хабр Карьеры
Разработчик баз данных PostgreSQL
Объединенные системы управления транспортом • Москва
До 220 000 ₽
DBA / Администратор баз данных PostgreSQL
СберТех • Москва
от 320 000 ₽
Программист C++ Builder / базы данных MySQL
RU Electronics • Москва
от 180 000 до 200 000 ₽
Ещё вакансии
Заказы с Хабр Фриланса
Настройка сервера
18 апр. 2024, в 21:56
2000 руб./за проект
Помощь с водпресс
18 апр. 2024, в 21:00
150 руб./за проект
Устранить проблемы с парсерами и отображением новостей
18 апр. 2024, в 20:08
7000 руб./за проект
Ещё заказы