Это смотря с чем сравнивать. Если с другими форумами, то очень хорошо. Но попробуй задать запрос "PHP MySQL", он находит всего 2348 тем, но обрабатывается очень долго. Тут уже каждый должен сам решить, устраивает ли его такая скорость. Я считаю, что это немного дольше, чем мне хотелось бы.
Чтобы узнать потенциальные возможности этого способа, достаточно простой арифметики. Обычно в базу слова помещают в том порядке, как они встретились при индексации, то есть без какого-либо порядка. То есть структура базы примерно такая:
word1 -> doc1
word2 -> doc1
word3 -> doc1
word4 -> doc2
word1 -> doc2
word3 -> doc3
word2 -> doc3
при этом во время поиска придется много прыгать по диску, собирая нужную информацию. Время доступа к данным у соверменных дисков около 10ms, то есть за одну секунду диск может прочесть ТОЛЬКО 100 строк из базы, если бы не было кеширования. И только благодаря многоуровневому кешированию данных (как самим диском, так и операционной системой, а иногда еще и самим приложением) позволяет многократно ускорить выборку. Очевидно, что с ростом числа строк в таблице никакие многомегабайтные кеши диска уже не смогут спасти и скорость выборки резко снизится из-за необходимости многократно перемещать головку диска.
Можно значительно ускорить данный алгоритм, если упорядочить базу таким образом:
word1 -> doc1
word1 -> doc2
word2 -> doc1
word2 -> doc3
word3 -> doc1
word3 -> doc3
word4 -> doc2
или еще лучше так:
word1 -> doc1,doc2
word2 -> doc1,doc3
word3 -> doc1,doc3
word4 -> doc2
Тогда диск сразу сможет прочесть всю нужную информацию и ее останется только обработать. Такая структура позволит работать с числом документов порядка миллиона. При дальнейшем росте мы упремся в другое ограничение - скорость передачи данных от диска в оперативную память. Если искомое слово содержится в 10000000 документов, то только список документов займет 40Мб (по 4 байта на указатель), а это уже примерная скорость передачи данных в современных системах. Чтобы обойти это ограничение, список документов сжимают (использую коды Голомба или нечто подобное), что позволяет получить менее одного байта на указатель. Если же выйти на уровень больших поисковых систем, то даже сжатие не даст особого выигрыша и там нужны еще более хитые алгоритмы. Например, можно список документов отсортировать по релевантности и при поиске не читать сразу весь список, а сначала только небольшую его часть. Если этого окажется достаточно, чтобы сформировать первую страницу с результатами, то дальше можно и не читать.
