Pull to refresh

Comments 12

Спасибо, попробуем.
Кстати говоря: для мониторинга индексов используем Cerebro, а для поиска, конечно, Kibana.
В качестве конвеера можно задействовать Logstash, который мощнее по функциональности и производительности встроенного в ingest node.
Я для управления и базового мониторинга использую ElasticHQ.
Ну и кластер конечно должен иметь нечётное количество нод.
Насколько я понимаю вопрос разделеления прав пока не рассматривали? Ведь при таком количестве документов наверняка найдётся информация с ограничением по доступности

Да, действительно такая проблема есть.
В рамках пилотного проекта проверка прав не требуется, но в дальнейшем план решения такой:


  1. Дофильтровывать результаты поиска уже на уровне приложения: вырезать хайлайт, если нет прав на файлы.
  2. По умолчанию отображать общедоступные данные, а при переходе в документ проверять права (сейчас так и есть, кроме хайлайта).
Мы в Apache SOLR использовали дополнительные таги со списком групп. И соответственно на уровне приложения использовали filter query. Но при добавлении/удалении прав доступа к документу была боль, так как SOLR не поддерживал атомарное изменение документа
А FSCrawler не пробовали. Недавно делал POC для подобного проекта и на намного более скромной виртуальной машине (всего 4GB для эластика) проиндексировал 1GB или 3000 файлов за 10 минут. Он использует TIKA для извлечения текста, как и эластик, плюс есть поддержка OCR, плюс извлекает кучу полезных метаданных.
Есть еще один проект Ambar, но что-то мне там не понравилось. Видимо, активность разработчиков…
Как я понял, FSCrawler индексирует файлы как отдельные документы. В нашем случае важно хранить файлы внутри документа, к которому они прикреплены (вместе с другой информацией, не связанной с файлами).
Для подходящей задачи обязательно попробуем, спасибо.
FSCrawler, помимо текстовой и мета информации, может отправить и сам оригинальный файл и сохранить его в индексе в бинарном формате. У меня тоже была задача хранить дополнительную информацию вместе с файлами в индексе. Так можно настроить mapping под свои бизнес задачи.
В любом случае ingest-attachment plugin тоже хорошее решение, просто я был немного удивлен столь малой скоростью. Я бы поигрался с настройками индекса, типа refresh interval, количеством реплик и нод.
5000 документов в час? Какой средний объем индексируемой информации в документе?
В данном случае документ включает в себя: данные карточки (счет идет на килобайты) и несколько вложений в формате docx, pdf, xlsx (файлы бывают самые разные от одностраничных до огромных по несколько мегабайт). Здесь ограничением больше выступает СЭД, которая отдает данные. Для elasticsearch такой поток ни о чем, не наблюдали задержек с его стороны при индексировании.
Понятно. Тогда лучше просто убрать упоминание о скорости индексирования из статьи. Оно просто нерелевантно.

Sign up to leave a comment.