С конца 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 – система полнотекстового поиска по документам
В процессе разработки мы держали в голове все те проблемы, которые нас преследовали с dtSearch. Поэтому нашими основными требованиями к системе были: лёгкая, интуитивно понятная, при этом мощная, и масштабируемая. Ориентировались мы сразу на объёмы в десятки и сотни миллионов файлов, обязательным условием был быстрый поиск, занимающий не более половины секунды независимо от сложности запроса и количества документов.
Релиз состоялся в январе 2017 г. Тогда мы запустили Ambar у первого крупного клиента.
Основные моменты о нашей системе, которые важно знать:
- Супербыстрый поиск с учётом особенностей языка: например, нечёткий поисковый запрос занимает около ста миллисекунд в более чем десятке миллионов файлов
- Лёгкий и понятный интерфейс, как для поиска, так и для администрирования
- Поддержка всех распространённых (и не очень) форматов файлов и дедубликация
- Лучший на рынке парсинг pdf, умное определение типа страницы (скан/текст)
- Продвинутый OCR
- Продвинутый полнотекстовый анализатор, теперь вы не потеряете информацию из-за неправильно токенизации дат, телефонов и пр.
- Простой REST API, лёгкая интеграция с чем угодно
- Возможность использования облачной версии или установка на собственном железе
- При установке на собственном железе возможна установка в кластере и масштабирование до петабайт данных
В ближайшее время мы планируем добавить возможность читать и индексировать содержимое почты и начать развивать аналитическую часть системы добавив распознавания именованных сущностей (фио, адреса, номера документов, идентификационные номера, телефоны).
→ Наш блог, где мы делимся всеми интересными фактами и наработками
Спасибо за внимание!
