Каковы недостатки использования каталога Lucene в качестве основного файлового хранилища?

Я хочу использовать Lucene MMapDirectory в качестве основного хранилища файлов. Каждый файл будет храниться в отдельном документе как массив байтов в StoredField. Все свойства файла, которые должны быть доступны для поиска, такие как имя файла, размер и т. Д., Будут храниться в индексируемых полях того же документа.

Мои вопросы были бы такими:

  1. Каковы недостатки использования каталогов Lucene для хранения файлов, особенно в отношении производительности индексации и поиска и потребления памяти (RAM)?
  2. Если это не запрет, есть ли лучший / более быстрый способ хранения файлов в каталоге, чем в виде массива байтов?

lucene file-storage memory-mapped-files memory-mapping
person xpages-noob    schedule 25.12.2017    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Короткий ответ

Я очень люблю Luсene и считаю ее лучшей библиотекой с открытым исходным кодом, но боюсь, что использовать ее в качестве основного источника файлов - не лучшее решение по следующим причинам:

  • высокие накладные расходы ЦП / памяти
  • низкая производительность индекса / запроса
  • высокая загрузка жесткого диска и удвоенный размер индекса
  • слабые возможности к восстановлению

Длинный ответ

Под капотом lucene использует следующие файлы для хранения всех сохраненных полей в одном сегменте:

  • файл индекса полей (.fdx),
  • файл данных полей (.fdt).

Вы можете узнать больше о том, как это работает, в Документы Lucene50StoredFieldsFormat.

  1. Это означает, что в случае каких-либо проблем с вводом-выводом восстановить какой-либо файл практически невозможно.
  2. Чтобы вернуть один файл, lucene должен читать и распаковывать двоичные данные с диска поблочно. Это означает высокую нагрузку на ЦП при распаковке и большой объем памяти, необходимый для хранения всего файла в пространстве кучи java. Также нет потоковой передачи - по сравнению с файловыми и сетевыми хранилищами.
  3. Максимальный размер документа ограничен реализацией кодека - 2 ГБ на документ.
  4. Lucene has a unique write-once segmented architecture: recently indexed documents are written to a new self-contained segment, in append-only, write-once fashion: once written, those segment files will never again change. This happens either when too much RAM is being used to hold recently indexed documents, or when you ask Lucene to refresh your searcher so you can search all recently indexed documents. Over time, smaller segments are merged away into bigger segments, and the index has a logarithmic "staircase" structure of active segment files at any time. This architecture becomes a big problem for file storage:
    • you can not delete file - only mark as unavailable
    • Операция слияния требует 2x дискового пространства и потребляет много ресурсов и пропускной способности диска - она ​​создает новый файл .fdt и копирует содержимое других файлов .fdt через код Java и память кучи Java
person Ivan Mamontov    schedule 02.01.2018
comment
Спасибо за отличный и подробный ответ. Поскольку я новичок в Lucene, я настолько полон энтузиазма, что пытаюсь решать все, что связано с поиском И хранением данных, используя только Lucene. Я рад, что такие люди, как вы, не торопятся, чтобы сообщить новичкам вроде меня, что у него также есть некоторые слабые места и что это не лучшее / оптимальное решение для каждой проблемы :) - person xpages-noob; 02.01.2018

arrow_upward
1
arrow_downward

Таким образом, вы будете использовать не MMapDirectory, а фактический индекс lucene.

У меня есть хороший опыт использования lucene в качестве основного хранилища данных для некоторых проектов.

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

Также убедитесь, что вы используете реализацию каталога, подходящую для вашего варианта использования. Я переключился на обычную реализацию RandomAccess в случае низкой нагрузки, поскольку она использует меньше памяти и работает почти так же быстро.

person sleeplessnerd    schedule 31.12.2017
comment
Спасибо за советы. Могу я спросить, возникали ли у вас когда-нибудь проблемы с надежностью при использовании индексов Lucene в качестве хранилищ данных? Согласно статьям, которые я прочитал, индекс, а также все сохраненные данные должны быть постоянными после вызова IndexWriter.commit(). Сталкивались ли вы на практике с проблемами, связанными с невосстановимыми данными или полностью поврежденными индексами? Очевидно, я бы не стал использовать Lucene для хранения большого количества файлов, если бы знал, что одна ошибка записи или сбой системы могут привести к повреждению всего хранилища. - person xpages-noob; 01.01.2018