Речь идёт ведь об обратных списках?
Если хранить вхождения в __обычных__ таблицах, то в таблице должно быть (в простом случае) 3 поля
[text_id] [word_id] [position]
итого, 3 числа на запись (не считаем байты)
при хранении в файле, путь до которого взаимно-однозначно соответствует word_id,
остаётся только два числа;
по мере роста индекса растёт не столько число таких файлов (за счёт новых слов), сколько их размер;
тогда издержки файловой системы состоят из двух частей - путь до файла и набор кластеров файла;
первая часть - константа, вторая - не более процента от объёма; в таком случае при росте индекса
отношение объёмов стремится к 3/2.
Причём файловая система очень хорошо оптимизирована для операции "взять файл по имени и читать его подряд",
а именно так и производится поиск списка документов/вхождений (в первом приближении список и есть результат).
Слияние списков также не противоречит данному подходу - параллельно читаются два заранее известных файла,
каждый из которых читается последовательно.
В базе данных требуется индекс чтобы просто найти вхождения одного слова. То есть сначала ищутся
вхождения word_id в записи таблицы, а потом читаются из этих записей text_id и position.
При простом индексировании (слова заносятся в порядке их нахождения в тексте) вхождения будут разбросаны
по всей таблице, их выборка будет заведомо медленнее чем чтение записей фиксированной структуры из последовательного файла.
Отношение объёма при наличии индекса уже в районе 2/1 и прибавки скорости на поиске по сравнению
с файлами не даст. Без индекса работа с такой таблицей практически невозможна (медленнее на порядки)
и сравнима с прямым поиском.
При создании же на основе базы данных файловой системы, мы вынуждены хранить собственно данные в полях типа
blob, что не даст выигрыша по сравнении с файловой системой на операции поиска, но сильно усложнит доступ к данным.
Другое дело - использовать базу данных для индексирования документов, то есть хранить в ней описания сайтов и
текстов, веса, служебную информацию для пауков и распределение данных по узлам кластера.
Что можно:
1. хранить индекс не в одном файле и не в одном файле на слово, а, например, файл на 256 слов.
Такой индекс сложнее обрабатывать, но удобнее использовать для поиска (нагрузка на файловую систему меньше)
Готовый файл индекса можно и сжать - больше нагрузка на проц, меньше - на ввод-вывод (если там узкое место)
2. сделать чтобы на каждой машине - свой кусок индекса и свой паук - тогда передача будет и вовсе не нужна;
если же захотите избыточность - передача снова потребуется; заметим, что rsync - достаточно сложный протокол,
который сам находит, что изменилось и передаёт разницу; может быть, (вычислительно) проще будет передавать
изменения, зная, что изменилось (процесс инициирует соединение, передаёт имя изменённого файла, его длину
и само содержимое файла - проще даже чем ftp).
3. прямой индекс преобразовывать в обратный только для не очень часто обновляемых страниц; 1-2% самых
"горячих" оставлять в прямом индексе - пока не остынут - позволит как избежать слишком частого перестраивания
индексов, так и перестраивать его не для каждого текста, а как накопится штук так 256. Поиск, соответственно,
проводится как по прямому, так и по обратному индексу, результаты объединяются. Побочный эффект - файл
появляется в поиске сразу же, как до него добредёт паук.
