Pull to refresh

Зачем мы создали замену старым системам поиска по документам

Reading time 4 min
Views 4.8K

С конца 2000-х мы занимались автоматизацией процессов в службах безопасности крупных компаний. Почти во всех компаниях одной из ключевых задач безопасности была проверка потенциальных клиентов и контрагентов на благонадёжность. Проверка включала в себя регулярный поиск информации о компаниях или людях в огромном массиве текстовой информации. Массив этот представлял (и по-прежнему представляет) собой несколько десятков миллионов документов в разных форматах и из разных источников. Это могли быть справки, отчеты, выписки в форматах pdf, doc, xls, txt, иногда сканы в тех же pdf, tiff и пр. В целом, задача быстрого поиска информации о какой-либо компании или человеке в этом массиве данных критически важна для любого бизнеса.


Мы прошли долгий путь от использования dtSearch до полноценного собственного решения. В этой статье хотим поделиться нашим опытом.


Для автоматизации процесса проверок мы использовали собственные решения, однако движком для полнотекстового поиска в документах у нас был dtSearch. Немного о нашем выборе (который был проведён в 2010 году и оставался с нами до осени 2016 года):


  • Выбор стоял между Cross, Copernic, Архивариус, dtSearch и несколькими экзотическими решениями
  • Сравнение скорости запросов на большом объёме данных показало очевидного победителя — dtSearch
  • У dtSearch на тот момент был самый развитый синтаксис запросов, который позволял нам реализовать все "тонкости" поиска информации
  • У dtSearch есть API в виде библиотеки для C#, которую мы использовали для интеграции движка в нашу систему. Не самый удобный вариант, но на то время был самым приемлемым

Что было дальше


Шли годы, наша система развивалась, и постепенно dtSearch становился узким и проблемным местом:


  • Непрерывно росли объёмы информации, вместе с этим падала скорость поиска, к концу 2016 года некоторые запросы занимали по 5 минут — абсолютно неприемлемый показатель
  • dtSearch не распознаёт сканированные документы (OCR), а таких документов становилось всё больше и больше — соответственно теряли много информации
  • dtSearch некорректно индексирует файлы в кодировке CP866
  • dtSearch не всегда корректно токенизирует фразы, номера, даты и слова, из-за чего может теряться информация, например, при поиске составных фамилий или номеров телефонов
  • Наши системы постепенно переехали с ASP.NET MVC/C#/MSSQL стека на более современный React/Node.js/Python/ElasticSearch/MongoDB, а с dtSearch можно интегрироваться только через С++ или C# API, из-за чего приходилось городить сложную интеграцию (очень хотелось REST)
  • Для индексатора dtSearch приходилось использовать полноценный Windows Server
  • dtSearch не умеет работать в кластере, что важно на огромных объёмах. Приходилось держать одну очень толстую машину специально для dtSearch

Список можно продолжить и дальше, но всё остальное — мелочи, по сравнению с проблемами, перечисленными выше.


Поэтому в определённый момент мы поняли, что больше так жить нельзя и нужно искать альтернативы или создать собственное решение. Поиск альтернатив, к нашему большому сожалению, ничего толкового не принёс, существовавшие в 2010 году продукты особо не продвинулись вперёд, а появившиеся новые (LucidWorks Fusion, SearchInform и пр.) нас совершенно не впечатлили.


Далее мы рассмотрели вариант создания модуля полнотекстового поиска для нашей системы, используя Apache Tika + ElasticSearch или Apache Solr, что в целом решило бы нашу проблему. Однако, нас не переставала мучать мысль о том, что на рынке по-прежнему нет хорошего решения с быстрым поиском, OCR и удобными интерфейсами.


Поэтому, не долго думая, мы решили создать собственное open-source решение, которое бы всем облегчило жизнь — так родился Ambar.


Ambar – система полнотекстового поиска по документам


Интерфейс Ambar


В процессе разработки мы держали в голове все те проблемы, которые нас преследовали с dtSearch. Поэтому нашими основными требованиями к системе были: лёгкая, интуитивно понятная, при этом мощная, и масштабируемая. Ориентировались мы сразу на объёмы в десятки и сотни миллионов файлов, обязательным условием был быстрый поиск, занимающий не более половины секунды независимо от сложности запроса и количества документов.


Релиз состоялся в январе 2017 г. Тогда мы запустили Ambar у первого крупного клиента.


Основные моменты о нашей системе, которые важно знать:


  • Супербыстрый поиск с учётом особенностей языка: например, нечёткий поисковый запрос занимает около ста миллисекунд в более чем десятке миллионов файлов
  • Лёгкий и понятный интерфейс, как для поиска, так и для администрирования
  • Поддержка всех распространённых (и не очень) форматов файлов и дедубликация
  • Лучший на рынке парсинг pdf, умное определение типа страницы (скан/текст)
  • Продвинутый OCR
  • Продвинутый полнотекстовый анализатор, теперь вы не потеряете информацию из-за неправильно токенизации дат, телефонов и пр.
  • Простой REST API, лёгкая интеграция с чем угодно
  • Возможность использования облачной версии или установка на собственном железе
  • При установке на собственном железе возможна установка в кластере и масштабирование до петабайт данных

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


Описание проекта и контакты


Страница проекта на GitHub


Наш блог, где мы делимся всеми интересными фактами и наработками


Спасибо за внимание!

Tags:
Hubs:
+12
Comments 12
Comments Comments 12

Articles