Подробная статья с описанием реальных прецедентов: http://www.intellectpro.ru/stat/index.php?view_id=86
Ни одной ногой не элементарные. Например, CRC32 ускоряет поиск но появляется неоднозначность обратного преобразования. Например, убирание имён я бы делать не стал. Например, Гугл не вставляет пробелы вместо знаков препинания. Они их сразу вырезает. Поэтому точка после предложения от следующего преложения должна быть отделена пробелом. Это удобнее при реализации. Совсем не затронута тема добавления новых документов в обратный индекс без остановки поискового движка. А это достаточно серьёзная проблема.
Если покопаетесь по форуму, то увидите, что для многих и многих написанное в статье совсем не элементарно: строят поиск на основе MySQL, Oracle и прочих. Хорошая статья.
В какой момент? После того, как органы разобрались в том, что реально есть на сайте?
Они в уходе совсем не виноваты ;)
Интересно, а раззиповка индексных файлов из памяти работает быстрее, чем чтение с диска?
Я так же делаю. ;)
Миллионы файлов это многовато. Но если использовать стемку, то их количество сильно уменьшается. Тысяч до ста, а с этим линуксы уже справляются. Можно ещё посмотреть в сторону BerkeleyDb - я пока не тестировал на необходимость беркли, но должно быть лучш. Если Вы храните индекс в одном файле, то там есть маленькая проблема. Добавление/удаление/изменение документа приводит к значительным операциям с этим файлом. Даже если он весь хранится в памяти, то сдвиги сотен мегабайт данных в памяти не сказка. Если кусочек оказывается на диске, то вообще получаются ужасы. С кучей маленьких файлов таких проблем нет.
Самый простой способ в Вашем случае хранить файл на диске, а смещения и часть индекса держать в памяти (кешь).
В Mirhosting хороший сервис. Как бывший клиент говорю.
Какое Ку? Откуда возьмётся второй нотариус? Он появится только после предъявления обвинения. Даже если к тому времени ФСБ не изымет сервер, они проведут все предварительные мероприятия по фиксированию нарушения прежде чем владелец форума узнает о предъявленно обвинении и сможет пойти к нотариусу.
Изучите свой рынок, пожалуйста.
Разбиваете обратный индекс по словам. Для каждого слова свой файл с обратным индексом. Файлы хранятся на диске. Если требуется большая производительность и время чтения с диска критично, то кидаете часто используемые файлы в memcached.
Соответственно, при построении обратного индекса Вы берёте базу документов и создаёте прямой индекс, сбрасывая его постепенно на диск (незачем ему хранится в памяти целиком). Затем для каждого уникального слова по очереди проходитесь по прямому индексу, составляете обратный индекс для этого слова, файл сбрасываете на диск. Таким образом, Вы можете индексировать базы любого размера. Правда количество проходов по прямому индексу получается равно количеству уникальных слов. Но это можно оптимизировать 🙄 Самое узкое место - дисковая подсистема. Это уже лечится только добавлением памяти.
