@Ogoun18 фев 2011 в 08:55

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

3 мин

4.5K

.NET *

+23

Комментарии 31

@SychevIgor 18 фев 2011 в 09:39

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

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

@antonlustin 18 фев 2011 в 10:52

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

@JeanLouis 18 фев 2011 в 15:19

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

@Ogoun 18 фев 2011 в 09:53

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

@SychevIgor 18 фев 2011 в 10:14

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

@kekekeks 18 фев 2011 в 10:20

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

@Ogoun 18 фев 2011 в 11:11

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

@kekekeks 18 фев 2011 в 13:02

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

@Ogoun 18 фев 2011 в 16:14

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

@kekekeks 19 фев 2011 в 17:21

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

@shodan 18 фев 2011 в 19:04

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

@Ogoun 18 фев 2011 в 11:12

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

@braindamaged 18 фев 2011 в 11:49

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

@Ogoun 18 фев 2011 в 12:19

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

@kekekeks 18 фев 2011 в 13:06

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

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

@Ogoun 18 фев 2011 в 13:21

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

@kekekeks 18 фев 2011 в 13:25

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

@selenite 18 фев 2011 в 17:46

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

@braindamaged 18 фев 2011 в 13:30

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

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

@Ogoun 18 фев 2011 в 14:02

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

@kekekeks 18 фев 2011 в 14:11

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

@Ogoun 18 фев 2011 в 14:57

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

@xonix 18 фев 2011 в 15:53

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

@Ogoun 18 фев 2011 в 16:16

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

@shodan 18 фев 2011 в 18:55

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

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

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

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

@Ogoun 18 фев 2011 в 19:22

xml

@shodan 18 фев 2011 в 19:41

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

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

@Ogoun 18 фев 2011 в 21:05

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

@uakomar 19 фев 2011 в 05:56

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

@Duke 7 окт 2012 в 18:30

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

@dionys 22 окт 2012 в 11:54

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий