Как ускорить поиск в большой коллекции текстовых файлов (1 ТБ)

Question

У меня есть набор текстовых файлов, содержащих анонимные медицинские данные (возраст, страна, симптомы, диагноз и т. Д. c). Эти данные насчитывают как минимум 30 лет, так что, как вы можете себе представить, у меня есть довольно большой набор данных. В общей сложности у меня около 20 000 текстовых файлов, примерно. 1 ТБ.

Периодически мне нужно будет искать в этих файлах вхождения определенной строки (не регулярного выражения). Каков самый быстрый способ поиска в этих данных?

Я пробовал использовать grep и рекурсивный поиск в каталоге следующим образом:

LC_ALL=C fgrep -r -i "searchTerm" /Folder/Containing/Files

Единственная проблема с выполнением вышеуказанного заключается в том, что это Поиск в этих данных занимает часы (иногда полдня!).

Есть ли более быстрый способ поиска в этих данных? На данный момент я открыт для различных подходов, таких как базы данных, elasticsearch и т. Д. c. Если я сделаю go по маршруту базы данных, у меня будет ок. 1 миллиард записей.

Мои единственные требования:

1) Поиск будет происходить на моем локальном компьютере (двухъядерный процессор и 8 ГБ ОЗУ)

2) I будет искать строки (не регулярное выражение).

3) Мне нужно будет увидеть все вхождения строки поиска и файла, в котором она находилась.

Answer 1

Уже есть много ответов, я просто хотел добавить свои два цента:

1. Наличие такого большого объема данных (1 ТБ) и всего 8 ГБ памяти будет недостаточно для любой подход, будь то использование Lucene или Elasticsearch (внутренне использует Lucene) или какой-либо команды grep, если вы хотите более быстрый поиск, по очень простой причине, все эти системы хранят данные в самой быстрой памяти, чтобы иметь возможность работать быстрее и из 8 ГБ (25% вы должны зарезервировать для ОС и еще 25-50% как минимум для другого приложения), у вас остается очень мало ГБ ОЗУ.
2. Обновление SSD, увеличение ОЗУ в вашей системе поможет, но это довольно громоздко, и опять же, если вы столкнетесь с проблемами производительности, будет сложно выполнить вертикальное масштабирование вашей системы.

Предложение

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

2. Что касается реализации, я бы предложил сделать это с помощью Elasticsearch (ES), так как его очень легко настроить и масштабировать. , вы даже можете использовать AWS Elasticsearch , который также доступен на бесплатном уровне, а затем быстро масштабируется, хотя я не большой поклонник AWS ES, это экономит много времени настройки, и вы можете быстро начать работу, если вы хорошо знакомы с ES.

3. Чтобы ускорить поиск, вы можете разделить файл на несколько полей (заголовок, тело, теги , author et c) и проиндексируйте только важное поле, что уменьшит размер инвертированного индекса, и если вы ищете только точное совпадение строки (без частичного или полнотекстового поиска), вы можете просто использовать keyword поле, которое еще быстрее индексируется и выполняет поиск.

4. Я могу go узнать, почему Elasticsearch хорош и как его оптимизировать, но не в этом суть. ttomline заключается в том, что для любого поиска потребуется значительный объем памяти, ЦП и диска, и любое из узких мест может затруднить поиск в локальной системе и других приложениях, поэтому советуем вам действительно подумать о том, чтобы сделать это во внешней системе, и Elasticsearch действительно выделяется как это среднее значение для распределенной системы и самой популярной на сегодняшний день поисковой системы с открытым исходным кодом.

Answer 2

Вам явно нужен указатель, как подсказывает почти каждый ответ. Вы можете полностью улучшить свое оборудование, но, поскольку вы сказали, что оно исправлено, я не буду вдаваться в подробности.

У меня есть для вас несколько важных указателей:

1. Только индекс поля, в которых вы хотите найти поисковый запрос, а не индексировать весь набор данных;
2. Создайте многоуровневый индекс (т. е. индекс по индексу), чтобы ваш поиск по индексу выполнялся быстрее. Это будет особенно актуально, если ваш индекс вырастет до более чем 8 ГБ;
3. Я хотел бы порекомендовать кеширование ваших поисковых запросов в качестве альтернативы, но это приведет к тому, что новый поиск снова займет полдня. Таким образом, предварительная обработка данных для создания индекса явно лучше, чем обработка данных по мере поступления запроса.

---

Незначительное обновление:

Много ответы здесь предлагают вам поместить данные в облако. Я настоятельно рекомендую, даже для анонимных медицинских данных, подтвердить источник (если вы не извлекли данные из Интернета), что это нормально.

Answer 3

Для ускорения поиска вам понадобится инвертированный индекс . Чтобы иметь возможность добавлять новые документы без необходимости повторно индексировать все существующие файлы, индекс должен быть инкрементным.

Одним из первых проектов с открытым исходным кодом, в которых была введена инкрементная индексация, является Apache Lucense. Это по-прежнему наиболее широко используемая система индексирования и поиска, хотя в настоящее время более популярны другие инструменты, расширяющие ее функциональные возможности. Elasiticsearch и Solr оба основаны на Lucense. Но пока вам не нужен веб-интерфейс, поддержка аналитических запросов, фильтрации, группировки, поддержка индексации нетекстовых файлов или инфраструктура для настройки кластера на нескольких хостах, Lucene по-прежнему остается лучшим выбором.

Apache Lucense - это библиотека Java, но она поставляется с полнофункциональным демонстрационным приложением на основе командной строки . Эта базовая c демоверсия уже должна обеспечивать все необходимые вам функции.

Имея некоторые знания Java, также будет легко адаптировать приложение к вашим потребностям. Вы будете удивлены, насколько прост исходный код демонстрационного приложения. Если Java не должен быть языком по вашему выбору, его оболочка для Pyhton, PyLucene также может быть альтернативой. Индексация демонстрационного приложения уже сведена практически к минимуму. По умолчанию не используются никакие расширенные функции, такие как выделение стеблей или оптимизация для сложных запросов - функции, которые, скорее всего, вам не понадобятся для вашего варианта использования, но которые увеличат размер индекса и время индексирования.

Answer 4

Можете ли вы подумать о передаче всех этих данных в elasticsearch, если они имеют согласованный формат структуры данных?

If yes, below are the quick steps:
1. Install filebeat on your local computer
2. Install elasticsearch and kibana as well.
3. Export the data by making filebeat send all the data to elasticsearch. 
4. Start searching it easily from Kibana.

Answer 5

Стоит рассмотреть топ c на двух уровнях: подход и c программное обеспечение для использования.

Подход : Исходя из того, как вы описываете данные, похоже, что предварительное индексирование окажет существенную помощь. Предварительное индексирование выполнит однократное сканирование данных и построит компактный индекс, который позволит выполнять быстрый поиск и определять, где c терминов отображаются в репозитории.

В зависимости от запросов, это позволит уменьшить или полностью исключить необходимость поиска в реальном документе даже для сложных запросов, таких как «найти все документы, в которых AAA и BBB встречаются вместе».

Specifi c Tool

Аппаратное обеспечение, которое вы описываете, относительно базовое c. Выполнение сложных поисков выиграет от большого объема памяти / многоядерного оборудования. Существуют отличные решения - elasti c search, solr и аналогичные инструменты могут выполнять magi c при наличии мощного оборудования для их поддержки.

Я считаю, что вы хотите рассмотреть два варианта, в зависимости от вашего навыки, и данные (это поможет образец данных может быть разделен) OP. * Создайте собственный индекс, используя облегченную базу данных (sqlite, postgresql), ИЛИ * Используйте облегченную поисковую систему.

Для второго подхода, используя описываемое оборудование, я бы рекомендовал изучить 'glimpse '(и вспомогательная утилита согласования). Glimple предоставляет способ предварительной индексации данных, что делает поиск чрезвычайно быстрым. Я использовал его в хранилище больших данных (несколько ГБ, но не ТБ).

См .: https://github.com/gvelez17/glimpse

* 1023 Elasti c Поиск, но настроить намного проще. Это без сервера. Основным преимуществом варианта использования, описанного OP, является возможность сканировать существующие файлы без необходимости загружать документы в дополнительный репозиторий поисковой системы.

Answer 6

Я вижу для вас 3 варианта.

1. Вам действительно стоит подумать об обновлении оборудования, обновление hdd -> ssd может увеличить скорость поиска в разы.

2. Увеличьте скорость поиска на месте. Вы можете обратиться к этому вопросу для получения различных рекомендаций. Основная идея этого метода - оптимизировать загрузку процессора, но вы будете ограничены скоростью вашего жесткого диска. Множитель максимальной скорости - это количество ваших ядер.

3. Вы можете индексировать свой набор данных. Поскольку вы работаете с текстами, вам понадобятся базы данных полнотекстового поиска. Elasticsearch и Postgres - хорошие варианты. Этот метод требует больше места на диске (но обычно меньше x2, в зависимости от структуры данных и списка полей, которые вы хотите проиндексировать). Этот метод будет бесконечно быстрее (секунды). Если вы решите использовать этот метод, внимательно выберите конфигурацию анализатора, чтобы соответствовать тому, что считается одним словом для вашей задачи ( вот пример для Elasticsearch)

Answer 7

Я думаю, что если вы кешируете самые последние медицинские данные, по которым проводился поиск, это может помочь с точки зрения производительности, вместо того, чтобы просматривать весь 1 ТБ, вы можете использовать redis / memcached

Answer 8

Fs Crawler может помочь вам в индексации данных в elasticsearch. После этого обычные запросы elasticsearch могут стать поисковой системой.