а что такие недешевые девелоперы. Это в России такие обитают? :-)
На самом деле все зависит от того, как разложить данные в MySQL. Вон недавно была статейка от Google BigTable, где рассказывается в частности про то, что поисковый индекс (по-крайней мере его часть) лежит в индексном файле. Ну MySQL будет менее производительным, но при умелом сочетании хранения в MySQL и plaintext разница будет небольшая. Ну раза в два-три в худшем случае. Для небольших поисковых сервисов, дешевле, железок накупить, чем устранять эту разницу. Вот если бы разница была в в более чем 10-20 раз, как в случае с прямым раскладыванием индекса в реляционные таблицы, тогда имеет смысл и покумекать.
Если мы поиск обсуждаем, то выплевывать приходится промили от того, что приходится лопатить для получения результата. Речь все-таки изначально шла о поиске?
А что вы все военные тайны поминует всуе? :-)
Я просто с начала немножко не понял про 320 мб, я думал, что это на одну машинку, а такое, наверное, не всякая мать потянет. Но если эти 320 мб между разными машинками распределяются...
Интересная тема. Ну про 60-80 мегов в рейде это понятно. А вот 320 - это интересно. Это на интеле??? Или все-таки, на сане?
Если брать классический ИФ, то там действительно для эффективной работы, нужно чтобы все кешировалось. Примерно по гигабайту ОЗУ на один миллион средних веб-документов. Или даже больше, если индекс не очень хорошо сжат. Но, вообще, говоря вдруг есть что-нибудь более эффективное чем классический индекс? Это вроде как факт пока недоказанный.
Кстати, Гугл, использует прунинг (эшелонирование). Страшный сон вебмастеров: страницы попали во второй эшелон (supplemental results)
Да что же тут невозможного-то???? Даже если это будет HTTP?
Каждый запрос идет с таймаутом. Кто не успел, тот опоздал. В результате, выборка иногда может зависить от того, кк сложились звезды. Так оно, обычно, и бывает.
Мы спорим, потому что Вы высказались в духе, что обычный сервер по 80 млн документам не может выполнять запросы. Вам объяснили, почему он это может делать.
По поводу архитектуры. Тут ИМХО два измерения.
1) Протокол опроса: corba, soap, собственный
2) Топология опроса. Варианты: линейная, когда один фронтенд сервер опраошивает все машины с индексами. Подоходит для средних сетей. Когда линейная не проходит, то нужно вводит машины второго или даже третьего эшелона, которые будут собирать промежуточные результаты. Типа, есть тысяча серверов поиска, 10 фронтенд машин и 100 промежуточных серваков, каждый из которых опрашивает 10 машин. Тогда фронтенд опрашивает десять промежуточных машин. В частности, наверное, логично, чтобы все такие машины были в одной подсети (физически в одном хабе). Тогда и задержки тоже будут минимальные.
Кстати, насчет эффективных методов. Это зависит от архитектуры. Если есть прямой индекс, по которому отрисовываются сниппеты, тогда да: можно жать по полной, потому что разархивировать нужно только по нажатию на ссылку: сохраненная копия.
А если прямой индекс не хранить, а сниппеты делать минимум по HTML тексту, то тут уже очень эффективные методы использовать нельзя, потому что они реально долго распаковывают. Причем до десяти раз медленее какого-нибудь LZ.
