Как поддерживать люценовые индексы в облачном приложении Azure

Question

Я только начал играть с библиотекой Azure для Lucene.NET (http://code.msdn.microsoft.com/AzureDirectory).. До сих пор я использовал свой собственный код для написания индексов lucene для большого двоичного объекта Azure. Итак, я копировал большой двоичный объект в localalstorageвеб-службы Azure и чтения / записи документов в индекс. Я использовал свой собственный механизм блокировки, чтобы убедиться, что у нас нет конфликтов между операциями чтения и записи в BLOB-объект. Я надеюсь, что библиотека Azure позаботится об этих проблемах дляme.

Однако, пробуя тестовое приложение, я настроил код для использования параметра составного файла, и он создавал новый файл каждый раз, когда я записывал в индекс. Теперь мой вопрос:сохранить индекс - т.е. сохранить моментальный снимок индексного файла и использовать его, если основной индекс поврежден, тогда как мне это сделать. Должен ли я сохранять резервную копию всех файлов .cfs, которые создаются или обрабатывают толькос последним все в порядке. Есть ли вызовы API для очистки большого двоичного объекта, чтобы сохранить последний файл после каждой записи в индекс?

TХэнкс Капил

Answer 1

После того, как я ответил на это, мы изменили нашу поисковую инфраструктуру и использовали Windows Azure Drive .У нас была рабочая роль, которая монтировала виртуальный жесткий диск с использованием блочного хранилища и размещала на нем индекс Lucene.NET.Код проверяется, чтобы убедиться, что виртуальный жесткий диск был смонтирован первым и существует каталог index.Если рабочая роль падает, виртуальный жесткий диск автоматически отключается через 60 секунд, и вторая рабочая роль может его забрать.

С тех пор мы снова изменили нашу инфраструктуру и перешли на Amazon с экземпляром Solr для поиска, но опция VHD хорошо работала во время разработки.это могло бы хорошо сработать в тестировании и производстве, но требования означали, что нам нужно перейти на EC2.

Answer 2

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

во-первых, опция составного файла: из того, что я читаю и выясняю, составной файл представляет собой один большой файл со всеми данными индекса внутри. все это приводит к тому, что в хранилище записывается множество файлов меньшего размера (настроенных с использованием функции SetMaxMergeDocs (int) IndexWriter). проблема в том, что как только вы получаете много файлов (я по глупости установил это около 5000), для загрузки индексов требуется время (на сервере Azure это занимает около минуты, от моего окна разработчика ... ну, его бегал уже 20 минут и все еще не закончил ...).

Что касается резервного копирования индексов, я еще не сталкивался с этим, но, учитывая, что у нас сейчас около 5 миллионов записей, и это будет расти, мне тоже интересно об этом. если вы используете один составной файл, возможно, загрузка файлов в рабочую роль, архивирование их и загрузка их с текущей датой будет работать ... если у вас есть меньший набор документов, вам может потребоваться повторная индексация данных если что-то пойдет не так ... но опять же, зависит от количества ....