Apache Lucene. Индексация больших файлов

@Shade-murderer · Регистрация: 22.12.2012

Студворк — интернет-сервис помощи студентам

Использую либо Apache Lucene 5.4.1(последняя на данный момент) в IntelliJ IDEA 14.
Индексирую мелкие файлы огромными пачками (долго правда, но всё проходит норм). Файлов миллион плюс-минус пара десятков тысяч, объёмом не больше метра. Получился индекс в 2.7 Гб из 37 Гб изначального объёма файлов.

Вопрос первый: почему IndexWriter не имеет метода optimize, который есть в .net реализации? Optimize полученный индекс складывает в меньшее количество файлов (после optimize в шарпе получалось около 10 файлов, а тут почти 40)?

Вопрос второй: как индексировать огромные файлы? Допустим размер в 5-15 гигов.
При индексации файлы занимают в оперативной памяти двукратный объём.

Вот код метода индексирования одного файла:

Java
1
2
3
4
5
6
7
8
9
private static void indexFile(IndexWriter writer, File file) throws IOException{
    if (file.isHidden() || !file.exists() || !file.canRead()){
        return;
    }
    Document doc = new Document();
    doc.add(new Field("content", new FileReader(file)));
    doc.add(new Field("filename", file.getCanonicalPath(), Field.Store.YES, Field.Index.ANALYZED));
    writer.addDocument(doc);
}

@Shade-murderer · 18.02.2016, 17:59 **[ТС]**

Если кому интересно, как была решена проблема.
Взял текстовый файл в 19 гигов и разбил поток на мелкие части, имитируя огромное количество маленьких файлов взамен этого большого. Сбор данных из потока для индексации собирался параллельно тому, как шла индексация прошлой части, чтобы не было лишних замедлений.
Получилось 5.5 Гб за час работы.
Optimize нет не случайно. Разработчики советовали никогда не использовать эту функцию (всех причин пока не выяснил, но это единственное объяснение). Похоже что-то не совсем хорошее проводилось при вызове этого метода.

Новые блоги и статьи Все статьи Все блоги /
Очистка реквизитов документа при копировании Maks 09.04.2026 Алгоритм из решения ниже применим как для типовых, так и для нетиповых документов на самых различных конфигурациях. Задача: при копировании документа очищать определенные реквизиты и табличную. . .	модель ЗдравоСохранения 8. Подготовка к разному выполнению заданий anaschu 08.04.2026 https:/ / github. com/ shumilovas/ med2. git main ветка * содержимое блока дэлэй из старой модели теперь внутри зайца новой модели 8ATzM_2aurI	Блокировка документа от изменений, если он открыт у другого пользователя Maks 08.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в конфигурации КА2. Задача: запретить редактирование документа, если он открыт у другого пользователя. / / . . .	Система безопасности+живучести для сервера-слоя интернета (сети). Двойная привязка. Hrethgir 08.04.2026 Далее были размышления о системе безопасности. Сообщения с наклонным текстом - мои. А как нам будет можно проверить, что ссылка наша, а не подделана хулиганами, которая выбросит на другую ветку и. . .
Модель ЗдрввоСохранения 7: больше работников, больше ресурсов. anaschu 08.04.2026 работников и заданий может быть сколько угодно, но настроено всё так, что используется пока что только 20% kYBz3eJf3jQ	Дальние перспективы сервера - слоя сети с космологическим дизайном интефейса карты и логики. Hrethgir 07.04.2026 Дальнейшее ближайшее планирование вывело к размышлениям над дальними перспективами. И вот тут может быть даже будут нужны оценки специалистов, так как в дальних перспективах всё может очень сильно. . .	Горе от ума kumehtar 07.04.2026 Эта мне ментальная установка, что вот прямо сейчас, мол, мне для полного счастья не хватает (нужное вписать), и когда я этого достигну - тогда и полный кайф. Одна из самых сильных ловушек на пути. . . .	Использование значений реквизитов справочника в документе, с определенными условиями и правами Maks 07.04.2026 1. Контроль срока действия договора Алгоритм из решения ниже реализован на примере нетипового документа "ЗаявкаНаРаботу", разработанного в конфигурации КА2. Задача: уведомлять пользователя, если. . .

@Shade-murderer 12 / 12 / 1 Регистрация: 22.12.2012 Сообщений: 26
	18.02.2016, 17:59 [ТС]
	Если кому интересно, как была решена проблема. Взял текстовый файл в 19 гигов и разбил поток на мелкие части, имитируя огромное количество маленьких файлов взамен этого большого. Сбор данных из потока для индексации собирался параллельно тому, как шла индексация прошлой части, чтобы не было лишних замедлений. Получилось 5.5 Гб за час работы. Optimize нет не случайно. Разработчики советовали никогда не использовать эту функцию (всех причин пока не выяснил, но это единственное объяснение). Похоже что-то не совсем хорошее проводилось при вызове этого метода. 0