The mnoGoSearch engine is integrated into PHP and broadly used. I recently found out that it can index database fields directly, in addition to crawling web pages. This seems well suited to indexing Drupal content.

Risks: The list of databases suported is long but not quite as extensive as PEAR DB. Also, I'm unsure how many PHP installations have mnoGo compiled in.

See http://www.mnogosearch.org/doc/msearch-extended-indexing.html#htdb for details on how to configure the indexer to crawl a database directly.

Comments

ax’s picture

ax commented

i did this 1 1/2 years ago [1] and it worked quite well. just nobody was interested in it ... probably because, as you mention, you won't find a host with mnoGoSearch installed and php configured to use it easily.

for a better search engine, we should probably have look at php only indexing search engine. there are quite some listed at [2]. anyone to evaluate them?

[1] http://drupal.kollm.org/mharc/html/drupal-devel/2001-11/msg00120.html (the demo doesn't work anymore)
[2] http://www.hotscripts.com/PHP/Scripts_and_Programs/Search_Engines/

al’s picture

al commented

I can't help but feel that indexing a database-driven site by spidering
its constructed pages is a complete waste of resources and time. It will
work particularly badly due to content in the sidebars, etc. and we'd
need to hack in a custom set of pages as mentioned so we just got the
article text.

Compared to simply using MySQL/MS-SQL's FULLTEXT indexing capabilities,
which will be *much* faster and a great deal simpler, I can't really see
the attraction. The only issue is Postgres. :(

What would be good would be a way to modularize the search stuff (it's
currently heavily tied to the node/comment modules and the current db
layout). That way, we could slot in different search engines as and when
we felt the need.

For example, people running MS-SQL or MySQL 4.0+ would take full
advantage of the native BOOLEAN FULLTEXT searches. Those with MySQL
3.23+ would use the FULLTEXT indexes, but have to hack BOOLEAN like we
do at the moment. Those with Postgres could use the existing system.

This would provide the biggest performance gain on most of our users
systems (MySQL) while giving enough flexibility to work anywhere. You'd
simply enable the search module of your choice.

ax’s picture

ax commented
Title: Explore mnoGoSearch as search engine » use native database indexing/searching capabilities (FULLTEXT/BOOLEAN/...) for drupal search

changed title

moshe weitzman’s picture

moshe weitzman commented

Apparently Postgres has two full-text search plugins. See tsearch2 and fulltextindex

Eric Scouten’s picture

Eric Scouten commented
Status: Active » Closed (won't fix)

Lots of work on search since then. No longer relevant.

kiev1.org’s picture

kiev1.org commented
Assigned: Unassigned » kiev1.org
Priority: Normal » Critical

To eat little bit better search engine http: // www.dataparksearch.org/

actively develops and has a forum of support http: // www.dataparksearch.org/cgi-bin/simpleforum.cgi

it is necessary in Drupal to add any beautiful conclusion of results