Pull to refresh

Comments 31

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

А то прям складывается впечатление, что для .net кроме обертки на Xapian ничего и нету
да и для сфинкса есть нетовский клиент
Есть и даже очень неплохие. Я использую SphinxConnector, правда он платный, но в отличии от бесплатных поддерживает SphinxQL. Что очень удобно. Получается эдакий укрупненный MySQL сервера. На 3306 порту, допустим, висит просто сервер MySQL висит, а на 3307 — Sphinx сервер, принимающий SphinxQL запросы. В реализации отличия вообще стираются, к какому серверу делать запрос решается программой.
Почитал, действительно есть. Ну и в причины выбора можно добавить более высокую производительность, и неограниченный размер базы даже для 32 битной системы(у Lucence ограничение в 2Gb, не хватило бы дяже для приведенного теста).
Спасибо. Теперь понятнее.
У нас в проекте просто база на Lucene.Net (правда не понятно что живее она или ее форк Aimee), только размер у нас вполне себе скромный.
Вы считаете, что если сишка, то обязательно быстрее? У меня на ноуте Lucene перемалывает 300 метров текста из мускульной базы за 90 секунд. 2GB — это лимит размера индексного файла, который в несколько раз меньше собственно текста. Да и проблемами с переносимостью из-за использования прекомпилированных бинарников Lucene не страдает.
На Xapiane при индексании всего текста файлов размер индексного файла перевалил за 3 Gb при тесте.
300 метров текста, индекс Lucene весит 40. Что я делаю не так?
Делаете вероятно не полнотекстовый индекс. В отличие от моего теста.
индексируется всё, работают запросы вида AND, OR, символы подстановки, выражения в кавычках, etc. Но сами документы не хранятся, только id.
стоп-слова включаешь, наверное!
И да, считаю что хорошо написанный код на С, будет быстрее аналогов на других ЯП не считая машинного кода и ассемблера.
Вы сначала найдите «хорошо написанный код на С»
Ну мне кажется *nix системы неплохо функционируют, а также сотни различных драйверов, примеров найти много можно. В том числе рассмотренный в этой статье продукт, результаты тестирования вполне устроили.
Вы сейчас сравнили прикладной и системный уровень, что, мягко говоря, некорректно. Ядро не сталкивается с задачей индексирования текста и прочими сложными алгоритмами. Там совершенно иной класс задач, который может быть выполнен нормально только на С.
Для прикладного же уровня обычно на производительность влияет не используемый язык, а алгоритм. Если у вас код работает за O(n3), то вы его хоть на асм перепишите, быстрее он от этого не станет.

Кстати, с этим вашим Xapian гемморой возникнет именно на этих самых *nix системах, где Lucene.Net не требует перекомпиляций и патчей, а просто работает «из коробки».
Не использую *nix системы, ничего не могу сказать по этому поводу. Насчет языков в целом согласен, писать для современного железа не так и важно на каком языке.
Дело не в железе, дело в экономии на спичках. Дотнет перемалывает данные с примерно той же скоростью, что и сишка, там разница в лучшем случае процентов 10 будет на таких задачах при усложнении кода в целом и оптимизаций на алгоритмы в частности. Вот если бы это был шедулер потоков, то тогда да, был бы смысл даже на асме писать.
В шедулере выигрыш разве будет? Переключение контекста из сишки компилируется в тот же набор инструкций /* сферическим компилятором завтрашнего дня */, а про O(n) вы писали выше.
А вы попробуйте Lucene.Net на вашей инфобазе. Или, если не NDA, скиньте её куда-нть, чтобы сообщество само потестировало.

P.S. Вообще хорошая тема для наброса сравнения — полнотекстовая индексация. На Хабре за наезды в адрес Сфинкс, например, вычислят по ip и будут угрожать :)
Попробую. Как раз занят подбором индексатора под Windows. Результат выложу.
Кстати, вы же не сохраняете в индексе сам документ полностью, я надеюсь? Есть мнение, что он раздулся именно из-за этого.
Именно так и делаю, весь полностью) И я понимаю что из-за этого раздулся. Делаю так специально. При реальном использовании будет индексировать только ключевые слова.
Что-то время индексации совершенно удручающее. Подозреваю, что затык в памяти и постоянный своп всё убивет. Могу только сказать, что у меня на хорошей конфигурации ~1.7 Гб текста индексируются в ~700 Мб индекса за минут 20 при этом позволяя искать по всем мыслимым запросам поддерживаемым Lucene: lucene.apache.org/java/2_9_1/queryparsersyntax.html
Первая причина — действительно своп, могу совершенно точно сказать что он замедляет работу в десятки, а то и сотни раз.
Вторая причина — индексирование всего текста файла, целиком.
> Показатели весьма оптимистичные, особенно для такой слабой машины.

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

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

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

Еще один совет кстати вспомнил: проверить полную (!) выдачу поиска. После того, как выяснилось, что до 90% фактически совпадающих документов Xapian тупо теряют — мои тесты в свое время быстро свернулись :)
Хорошо, обязательно проверю)
Спасибо за демонстрацию еще одного подхода. Я пользуюсь Lucene при индексации. Он же используется при подсветке найденных результатов. Поддерживаю стремление увидеть сравнительную характеристику между тремя подходами. Если вам нужна будет помощь с Lucene, обращайтесь, чем могу, помогу.
1) Почему-то при каждом сканировании документов в базу добавляются всё те же документы. Простого способа как не добавлять дубликаты я не нашел.
2) Хотя в исходном коде используется стемминг, у меня он так и не заработал.
Чтобы не добавлялись одни и те же документы, нужно для каждого документа генерировать уникальный идентификатор и добавлять его в документ с префиксом Q (такой префикс предлагает документация Omega), а затем использовать метод API replace_document_by_term с этим термом. В случае, если документ с таким термом уже есть, он будет заменён, а иначе — добавлен.
Only those users with full accounts are able to leave comments. Log in, please.