mnoGoSearch: индексирование таблиц, сортировка

А насколько оправдано вообще индексирование БД напрямую? не лучше ли индексировать непосредственно веб-страницы? Проблем точно будет меньше :)

Кстати, поделитесь опытом: что Вы в итоге делаете с результатами индексирования именно БД?

Все зависит от сайта. На нашем сайте публикации существуют в виде файлов (генерируются CMS), но форумы, blogs и коллеция ссылок показываются динамически. На настоящий момент на форумах сайта больше 120 000 сообщений. Осуществлять обычный поиск средствами SQL через LIKE - неэффективно. Генирировать 120 000 файлов, чтобы все это дело проиндексировать, кажется не совсем правильным. mnoGoSearch позволяет индексировать таблицы, имеющие PRIMARY KEY. В качестве ссылок храняться ссылки на скрипты, которые отображают содержание таблиц. К сожалению, в связи с упомянутым багом удается проиндексировать только 25 000 сообщений форумов. На одном из форумов нашел сообщение, что Карташов собирается исправить, но исправил ли - неизвестно (в stable version 3.1.21

баг сохраняется). Есть еще вариант скормить индексеру файл с ссылками, которые надо проиндексировать, но тогда это надо делать через HTTP, что жалко.

Поиск не отличается от поиска по по обычным страницам. Большое преимущество состоит в том, что можно представить один коплексный поиск по разным разделам сайта. (Выбор разделов осуществляется через категории, которые тоже можно задать в mnoGoSearch)

Можно попробовать более позднюю версию: 3.2.10 работает вроде вполне устойчиво (во всяком случае, у меня), 3.2.12 не пробовал. Правда, как там с базами -- не знаю: я (благо, не так много) по http прямо страницы и скармливаю. А скормить файл со ссылками на скрипты по HTTP -- если mnogosearch на той же машине -- чего ж жалко-то? :) Ну, может, медленнее будет. Есть, правда, риск, что будет выдавать постоянно network error, если нагрузка на сервере большая (у меня такое было один раз)...

P.S. Максим Захаров, кстати, появляется здесь, может, он что подскажет...

Версия 3.1.х не поддерживается, там правятся только баги, связанные с безопасностью. Поэтому лучше использовать версию 3.2.х, да и документация на 3.2 намного лучше и есть на русском (входит в дистрибутив)

1. здесь скорее всего дело не в mnogosearch, а в команде HTDBDoc, которая в любом случае возвращает ответ HTTP 200 вне зависимости от присутствия документа в базе.

2. Эт не проблема mnogosearch, вернее не совсем его. При выполнении команды HTDBList высасывается весь ответ сервера, а его выполение зависит от системы, хватит ли у неё ресурсов переварить такой ответ. Хотя возможно ещё на это влияет максимально возможный размер документа, по-моему в 3.1. он может изменяться только с перекомпиляцией.

3. чего нет, того нет.

В любом случае, советую пропробовать 3.2

Для 3.2.10 и более ранних версий есть эксплоит, дающий возможность выполнения команд через дырку в search.cgi, правда работающий только под Linux, но всё равно лучше проапгрейдиться.

Спасибо за совет, так и поступим в ближайшее время.

Это верно только для search.cgi или распространяется на PHP extensions тоже?

Не знаю, если php extensions CGI-запрос разбирают при помощи библиоткеки mnogosearch, то да, а если сами, то не известно.

Есть почтовые рассылки ru@mnogosearch.org и php@mnogosearh.org - их девелоперы наверняка читают. См. http://www.mnogosearch.org/list.html

В текущей CVS версии 3.2.х добавлена возможность сортировки результатов по дате. Если хотите, можете поспробовать последний снапшот.

Насколько стабильна 3.2.x?

Исправлена проблема с индексацией больших таблиц?

Какие известны баги?

Насколько сложен процес миграции с предыдущей версии на новую?