как у них это все работает???

Далеко не все можно прочитать, ...

А рассказать? Возьми да расскажи :)

Обмен должен быть полезен всем сторонам, ...

Artisan, Ага...

хорошо... допустим у них индекс хранится на разных серверах (то есть часть там там и там) размер считываемых данных сократится = но все равно винт читает 60мб/с (около того)

4LF, Ну и что? Все зависит от того, какого размера индексный файл... и вообще с чего вы взяли, что индекс у того же яндекса хранится не в оперативке?

Насколько я знаю у Google индекс полностью хранится в оперативной памяти, ...

Поиск ведется параллельно по всем (или по части) серверам кластера. Поэтому и скорость винчестера на время "отклика" влияет не значительно. Такая организация индекса иногда называется локальный инвертированный индекс - http://www.google.com/search?q=local+inverted+%28index+%7C+file%29

Кроме того индексы еще можно и компрессировать - http://citeseer.ist.psu.edu/scholer02compression.html

eshum, честно говоря про "локальный инвертированный индекс" не стал читать = но примерно понял на каждом сервере хранится часть индекса одного слова, и тогда при запросе параллельно считываются пост-листы (поэтому получается так быстро?)

а если все организовать на одном сервере (не смейтесь), то как организовать индекс?

я просто делаю на BerkeleyDB (b+tree) key это id_слова value пост-лист (пока только массив id_страниц). Например предлог "и" то мой пост-лист будет содержать столько элементов сколько проиндексировано страниц (например 1 000 000).

Этот массив нужно как-то сохранить в value (делаю на perl'e использую функцию pack и unpack; итог pack ~1сек unpack ~1сек + 1сек на считывание value), прокомментируйте/посоветуйте пожалуйста

4LF,

Ну, во-первых, для слов вроде предлога "и" существует стоп-лист, или просто список служебных частей речи, которые сами по себе ценности в запросе не составляют. По таким индексные пост-листы строить не стоит.

Во-вторых, если вы решили строить все на одном сервере, поможет кэширование. Если не полное - ведите умную статистику запросов, которая будет отбирать самые популярные и хранить по ним кэши. Ну, тут уж все решают ваши алгоритмы, за вас их никто не придумает...

И раз мы заговорили о кэшировании, полагаю, что механизмы кэширования легче осуществлять, наверное, на собственной СУБД...