Чтож, Ваши слова еще раз подтверждают, что это проблема дизайна mnoGoSearch.
Я, конечно, понимаю, что, как Вы написали, HTTDB надо уметь пользоваться (я бы, наверное, сюда не писал, если бы был mnoGoSearch гуру), но цитирую слова создателя mnoGoSearch Александра Баркова о проблеме индексирования больших таблиц:
Yes, this is known longstanding problem.
It even remains in latest 3.2.x CVS sources.
OK. I'll finally fix this today in CVS.
For 3.1.19 the workaround is to use LIMIT,
as you already did. Another thing is to use
bigger MaxDocSize. It is 1M by default, you can
set it to for example 3M.
http://www.mnogosearch.org/board/message.php?id=4286
А относительно того, чтобы написать несколько запросов. Это, наверное, возможно, хотя у меня была проблема, когда мне надо было проиндексировать два раза одну и ту же таблицу, но в URL должны были быть разные параметры. mnoGoSearch игнорировал второй скан таблицы. Мне пришлось поменять URL в HTDBList (в первом случае использовать http://www.xyz.com, а во втором http://xyz.com) и тогда все заработало.
С другой стороны писать несколько запросов - явный танец с бубнами, так как надо постоянно менять конфигурационный файл, чтобы покрывать прибавляющиеся записи.
HTDB - это не workaround, a feature, которая положительно отличает mnoGoSearch от некоторых конкурентов. Только было бы неплохо, если бы она нормально работала.
Спасибо!
Означает ли это, что проблема с индексацией больших таблиц не стоит и в текущей стабильной версии?
Если да, то практика говорит об обратном.
Мне не совсем понятно относительно железа. Речь же не идет о загрузке всей таблицы в память. Мне казалось, что HTDBList грузит только индекс и потом выполняет HTDBDoc для каждого значения индекса. Если это сделано по другому, то это проблема не железа, а дизайна mnoGoSearch (поймите правильно, продукт хороший, бесплатный, но хочется лучше...).
(Я могу запустить запрос с PHP и он без проблем покажет мне индексы 120 000 записей.)
Как бы там не было, большие таблицы существуют в природе :-), поэтому было бы логично попытаться найти workaround для существующей проблемы. В конечном итоге, почему бы не индексировать такие таблицы порциями?
Насколько стабильна 3.2.x?
Исправлена проблема с индексацией больших таблиц?
Какие известны баги?
Насколько сложен процес миграции с предыдущей версии на новую?
Это верно только для search.cgi или распространяется на PHP extensions тоже?
Все зависит от сайта. На нашем сайте публикации существуют в виде файлов (генерируются CMS), но форумы, blogs и коллеция ссылок показываются динамически. На настоящий момент на форумах сайта больше 120 000 сообщений. Осуществлять обычный поиск средствами SQL через LIKE - неэффективно. Генирировать 120 000 файлов, чтобы все это дело проиндексировать, кажется не совсем правильным. mnoGoSearch позволяет индексировать таблицы, имеющие PRIMARY KEY. В качестве ссылок храняться ссылки на скрипты, которые отображают содержание таблиц. К сожалению, в связи с упомянутым багом удается проиндексировать только 25 000 сообщений форумов. На одном из форумов нашел сообщение, что Карташов собирается исправить, но исправил ли - неизвестно (в stable version 3.1.21
баг сохраняется). Есть еще вариант скормить индексеру файл с ссылками, которые надо проиндексировать, но тогда это надо делать через HTTP, что жалко.
Поиск не отличается от поиска по по обычным страницам. Большое преимущество состоит в том, что можно представить один коплексный поиск по разным разделам сайта. (Выбор разделов осуществляется через категории, которые тоже можно задать в mnoGoSearch)
