Индексирование и поиск с помощью Xapian в .NET

[SychevIgor]

«Мной он был выбран из этих трех продуктов за возможность использования из .Net.»
Раскройте смысл этой фразы пожалуйста несколько подробнее.
Тк Apache Lucene имеет вообще .net версию, у которой есть еще и форк к тому же.

А то прям складывается впечатление, что для .net кроме обертки на Xapian ничего и нету

[antonlustin]

да и для сфинкса есть нетовский клиент

[JeanLouis]

Есть и даже очень неплохие. Я использую SphinxConnector, правда он платный, но в отличии от бесплатных поддерживает SphinxQL. Что очень удобно. Получается эдакий укрупненный MySQL сервера. На 3306 порту, допустим, висит просто сервер MySQL висит, а на 3307 — Sphinx сервер, принимающий SphinxQL запросы. В реализации отличия вообще стираются, к какому серверу делать запрос решается программой.

[Ogoun]

Почитал, действительно есть. Ну и в причины выбора можно добавить более высокую производительность, и неограниченный размер базы даже для 32 битной системы(у Lucence ограничение в 2Gb, не хватило бы дяже для приведенного теста).

[SychevIgor]

Спасибо. Теперь понятнее.
У нас в проекте просто база на Lucene.Net (правда не понятно что живее она или ее форк Aimee), только размер у нас вполне себе скромный.

[kekekeks]

Вы считаете, что если сишка, то обязательно быстрее? У меня на ноуте Lucene перемалывает 300 метров текста из мускульной базы за 90 секунд. 2GB — это лимит размера индексного файла, который в несколько раз меньше собственно текста. Да и проблемами с переносимостью из-за использования прекомпилированных бинарников Lucene не страдает.

[Ogoun]

На Xapiane при индексании всего текста файлов размер индексного файла перевалил за 3 Gb при тесте.

[kekekeks]

300 метров текста, индекс Lucene весит 40. Что я делаю не так?

[Ogoun]

Делаете вероятно не полнотекстовый индекс. В отличие от моего теста.

[kekekeks]

индексируется всё, работают запросы вида AND, OR, символы подстановки, выражения в кавычках, etc. Но сами документы не хранятся, только id.

[shodan]

стоп-слова включаешь, наверное!

[Ogoun]

И да, считаю что хорошо написанный код на С, будет быстрее аналогов на других ЯП не считая машинного кода и ассемблера.

[braindamaged]

Вы сначала найдите «хорошо написанный код на С»

[Ogoun]

Ну мне кажется *nix системы неплохо функционируют, а также сотни различных драйверов, примеров найти много можно. В том числе рассмотренный в этой статье продукт, результаты тестирования вполне устроили.

[kekekeks]

Вы сейчас сравнили прикладной и системный уровень, что, мягко говоря, некорректно. Ядро не сталкивается с задачей индексирования текста и прочими сложными алгоритмами. Там совершенно иной класс задач, который может быть выполнен нормально только на С.
Для прикладного же уровня обычно на производительность влияет не используемый язык, а алгоритм. Если у вас код работает за O(n³), то вы его хоть на асм перепишите, быстрее он от этого не станет.

Кстати, с этим вашим Xapian гемморой возникнет именно на этих самых *nix системах, где Lucene.Net не требует перекомпиляций и патчей, а просто работает «из коробки».

[Ogoun]

Не использую *nix системы, ничего не могу сказать по этому поводу. Насчет языков в целом согласен, писать для современного железа не так и важно на каком языке.

[kekekeks]

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

[selenite]

В шедулере выигрыш разве будет? Переключение контекста из сишки компилируется в тот же набор инструкций /* сферическим компилятором завтрашнего дня */, а про O(n) вы писали выше.

[braindamaged]

А вы попробуйте Lucene.Net на вашей инфобазе. Или, если не NDA, скиньте её куда-нть, чтобы сообщество само потестировало.

P.S. Вообще хорошая тема для наброса сравнения — полнотекстовая индексация. На Хабре за наезды в адрес Сфинкс, например, вычислят по ip и будут угрожать :)

[Ogoun]

Попробую. Как раз занят подбором индексатора под Windows. Результат выложу.

[kekekeks]

Кстати, вы же не сохраняете в индексе сам документ полностью, я надеюсь? Есть мнение, что он раздулся именно из-за этого.

[Ogoun]

Именно так и делаю, весь полностью) И я понимаю что из-за этого раздулся. Делаю так специально. При реальном использовании будет индексировать только ключевые слова.

[xonix]

Что-то время индексации совершенно удручающее. Подозреваю, что затык в памяти и постоянный своп всё убивет. Могу только сказать, что у меня на хорошей конфигурации ~1.7 Гб текста индексируются в ~700 Мб индекса за минут 20 при этом позволяя искать по всем мыслимым запросам поддерживаемым Lucene: lucene.apache.org/java/2_9_1/queryparsersyntax.html

[Ogoun]

Первая причина — действительно своп, могу совершенно точно сказать что он замедляет работу в десятки, а то и сотни раз.
Вторая причина — индексирование всего текста файла, целиком.

[shodan]

> Показатели весьма оптимистичные, особенно для такой слабой машины.

Машина нормальная, именно на такой в свое время индексировал 100 мег за пару минут :)

Советую еще проверить время более сложного поиска, чем «первые 100 матчей и прикидка числа совпадений», может сильно отличаться.

А файлы текстовые или doc/pdf/...?

[Ogoun]

xml

[shodan]

Ага, спасибо. Те. неделю заняла по сути индексация вчистую, без всякого разбора документов. Очень круто на самом деле — мне б терпения ждать не хватило :)

Еще один совет кстати вспомнил: проверить полную (!) выдачу поиска. После того, как выяснилось, что до 90% фактически совпадающих документов Xapian тупо теряют — мои тесты в свое время быстро свернулись :)

[Ogoun]

Хорошо, обязательно проверю)

[uakomar]

Спасибо за демонстрацию еще одного подхода. Я пользуюсь Lucene при индексации. Он же используется при подсветке найденных результатов. Поддерживаю стремление увидеть сравнительную характеристику между тремя подходами. Если вам нужна будет помощь с Lucene, обращайтесь, чем могу, помогу.

[Duke]

1) Почему-то при каждом сканировании документов в базу добавляются всё те же документы. Простого способа как не добавлять дубликаты я не нашел.
2) Хотя в исходном коде используется стемминг, у меня он так и не заработал.

[dionys]

Чтобы не добавлялись одни и те же документы, нужно для каждого документа генерировать уникальный идентификатор и добавлять его в документ с префиксом Q (такой префикс предлагает документация Omega), а затем использовать метод API replace_document_by_term с этим термом. В случае, если документ с таким термом уже есть, он будет заменён, а иначе — добавлен.