Как улучшить производительность Lucene в распределенной среде?

Я сталкиваюсь с длительным временем поиска (порядка 10 секунд) при поиске по реализации мастер-осколка в распределенной среде. Однако тот же запрос через Luke возвращается в миллисекундах.

Приложение представляет собой распределенную систему. Все узлы имеют общее монтирование NFS, в котором находятся индексы. Для простоты рассмотрим два узла Node1 и Node2. Элементы /etc/fstab выглядят следующим образом.

nfs:/vol/indexes /opt/indexes nfs rw,suid,nodev,rsize=32768,wsize=32768,soft,intr,tcp 0 0

Существует несколько каналов (скажем Feed1 и Feed2), которые попадают в систему, и для каждого из фидов на node и для каждого фида есть осколок. Индексы выглядят как

Feed1-master
Feed1-shard-Node1.com
Feed1-shard-Node1.com0
Feed1-shard-Node1.com1

Код, выполняющий поиск,

FeedIndexManager fim = getManager(feedCode);
searcher = fim.getSearcher();
TopDocs docs = searcher.search(q, filter, start + max, sort);

private FeedIndexManager getManager(String feedCode) throws IOException {
  if (!_managers.containsKey(feedCode)) {
    synchronized(_managers) {
      if (!_managers.containsKey(feedCode)) {
        File shard = getShardIndexFile(feedCode);
        File master = getMasterIndexFile(feedCode);
        _managers.put(feedCode, new FeedIndexManager(shard, master));
      }
    }
  }  
  return _managers.get(feedCode);
}

FeedIndexManager выглядит следующим образом.

public class FeedIndexManager implements Closeable {

  private static final Analyzer WRITE_ANALYZER = makeWriterAnalyzer();
  private final Directory _master;
  private SearcherManager _searcherManager;
  private final IndexPair _pair;

  private int _numFailedMerges = 0;
  private DateTime _lastMergeTime = new DateTime();

  public FeedIndexManager(File shard, File master) throws IOException {
    _master = NIOFSDirectory.open(master, new SimpleFSLockFactory(master));

    IndexWriter writer = null;
    try {
      writer = new IndexWriter(_master,
                               WRITE_ANALYZER, 
                               MaxFieldLength.LIMITED);
    } finally {
      if (null != writer) {
        writer.close();
      }
      writer = null;
    }

    _searcherManager = new SearcherManager(_master);
    _pair = new IndexPair(_master,
                          shard, 
                          new IndexWriterBuilder(WRITE_ANALYZER));
  }

  public IndexPair getIndexWriter() {
    return _pair;
  }

  public IndexSearcher getSearcher() {
    try {
      return _searcherManager.get();
    }
    catch (IOException ioe) {
      throw new DatastoreRuntimeException(
        "When trying to get an IndexSearcher for " + _master, ioe);
    }
  }

  public void releaseSearcher(IndexSearcher searcher) {
    try {
      _searcherManager.release(searcher);
    }
    catch (IOException ioe) {
      throw new DatastoreRuntimeException(
        "When trying to release the IndexSearcher " + searcher
        + " for " + _master, ioe);
    }
  }

  /**
   * Merges the changes from the shard into the master.
   */
  public boolean tryFlush() throws IOException {
    LOG.debug("Trying to flush index manager at " + _master
              + " after " + _numFailedMerges + " failed merges.");
    if (_pair.tryFlush()) {
      LOG.debug("I succesfully flushed " + _master);
      _numFailedMerges = 0;
      _lastMergeTime = new DateTime();
      return true;
    }
    LOG.warn("I couldn't flush " + _master + " after " + _numFailedMerges
             + " failed merges.");
    _numFailedMerges++;
    return false;
  }

  public long getMillisSinceMerge() {
    return new DateTime().getMillis() - _lastMergeTime.getMillis();
  }

  public long getNumFailedMerges() {
    return _numFailedMerges;
  }

  public void close() throws IOException {
    _pair.close();
  }

  /**
   * Return the Analyzer used for writing to indexes.
   */
  private static Analyzer makeWriterAnalyzer() {
    PerFieldAnalyzerWrapper analyzer = 
      new PerFieldAnalyzerWrapper(new LowerCaseAnalyzer());

    analyzer.addAnalyzer(SingleFieldTag.ID.toString(), new KeywordAnalyzer());
    // we want tokenizing on the CITY_STATE field
    analyzer.addAnalyzer(AddressFieldTag.CITY_STATE.toString(),
            new StandardAnalyzer(Version.LUCENE_CURRENT));
    return analyzer;
  }
}

Убийца, который потребляет около 95-98% задержки, - это вызов, для поиска требуется около 20 секунд, тогда как если индекс открывается через Luke, он находится в миллисекундах.

TopDocs docs = searcher.search(q, filter, start + max, sort);

У меня есть следующие вопросы.

  • Правильно ли иметь несколько мастеров на канал или я должен уменьшить его до одного мастера? Число элементов в индексе составляет около 50 миллионов.

  • Задержка невелика в каналах, где количество объектов меньше миллиона (второй ответ). Каналы, в которых объекты составляют более 2 миллионов, занимают около 20 секунд. Должен ли я поддерживать только 1 осколок за node против 1 осколка за node за канал?

  • Слияние с Осколка на мастера предпринимается каждые 15 секунд. Если этот параметр будет изменен?

В настоящее время я использую Lucene 3.1.0 и JDK 1.6. Ячейки представляют собой два 64-битных ядра с 8 Гб ОЗУ. В настоящее время JVM работает с максимальным размером 4 ГБ.

Любое предложение улучшить производительность высоко ценится. Я уже выполнил всю стандартную настройку производительности, которая обычно назначается Lucene. Большое спасибо за чтение этой длинной почты.

Ответ 1

Это не тот ответ, который вы искали, возможно, но посмотрите Упругий поиск. Это распределенный кластерный сервисный уровень вокруг Lucene, который запрашивается через HTTP или может быть запущен встроенным.

И это быстро, довольно смешно. Кажется, он настроил Lucene должным образом под обложки, все еще подвергая все варианты конфигурации Lucene, если вам нужно их использовать.

Выполнение Lucene в распределенной среде сложно, так как вы обнаруживаете, вы оказываетесь в неприятных проблемах с блокировкой. ElasticSearch предназначен для решения этой конкретной проблемы, поэтому вы можете решить другие.