Crawl-delay работает только для яхи (хотя возможно что неофициально - гугл также его учитывает).
Lor, кеширование - это правильно, но есть вещи где его нельзя применять.
В общем отчасти краул-делай спас (немного), а отчасти (вернее в основном) оптимизация настроек апача\рнр помогла.
подобные вещи надо оценивать по качеству работы и по величине бидов.
И то и другое у СЕпартнершип на отличном уровне.
Организаторы почему то скромно умолчали о том, что они оплачивают 100% от бидов которые идут в фиде.
Подобный процент, до этого момента, своим партнерам не предоставляла ни одна компания.
И фид работает быстро и без сбоев, что тоже весьма важно.
В общем на мой взгляд, из всех РРС которые появились за последний год, - эта самая професиональная.
а что такие цели то мелкие ? давайте не фонд, а партию тогда уж создавать.
предлагаю так же:
1. путем голования членов партии, по каждому кейворду, определять список сайтов и их распределение в СЕРП.
2. ПР выдавать только членам партии, после рассмотрения кандидатуры на всеобщем собрании.
3. Всех кто не примкнул к партии - обьявить врагами народа. ПР национализировать. Гугл передать в руки партии оптимизаторов.
з.ы. манифест оптимизатора помниться здесь уже был. даже составлять ненадо будет. :)
практически у всех крупных РРС за исключением овертуры и файндвота - рускоязычные владельцы :)
а насчет бидов и прочего... вы вначале сделайте, а через пол года вернемся к этой теме.
Leom, респект.
а под linux есть разработки подобные ?
офтоп: не дадите консультацию о том как получить патент на поисковые\интелектуальные технологии в штатах ?
вообще от реализации зависит. думаю послезавтра эта страница будет в гугле и сам сможешь проверить.
p.s. наш поисковик проиндексил этот текст как "Самое важное" в обоих случаях. но у нас и движок свой.
2-е
Chuck, такое впечталение что вы несколько заблуждаетесь в представлении о работе пауа.
1. задача паука - идти по заданному списку ссылок и подготовить информацию (тект\ссылки) для последующей обработки. естественно эта информация храниться ЛОКАЛЬНО,
и никто не скачивает несколько раз страницу для того чтобы вначале выдернуть из нее линки,потом текст, а потом разметку хтмл или еще что то.
2. пауком можно называть как скрипт который непосредственно скачивает (проверяет) нужный контент, но и набор скриптов которые не только скачивают, но и анализируют контент.
3. можно в одном скрипте совместить и закачку контента, и его анализ, но если вы собираетесь индексировать большие обьемы информации (а у вас это и подразумевается), то у вас возникнет проблема простоя мощностей.
обьясню на примере...
допустим скрипту требуется 1 секунда на то чтобы закачать документ и еще 1 секунда уходит на его обработку.
если эти функции совмещены в одном скрипте то за 1 минуту вы сможете проиндексировать всего 30документов.
при этом у вас простаивает 50% от процессора (во время загрузки документа) и 50% от загрузки канала (во время анализа).
а если этим занимаются паралельные скрипты то за минуту вы индексируете 60документов.
далее все будет веселее, если у вас однопотоковая система то у вас в любом случае получается что будут колосальные простои мощности (особенно если в списке урлов попадеться один сайт который будет тормозить или отваливаться по таймауту секунд этак через 60), поэтому надо делать многопоточную систему. способную к распределенным вычислениям и постановкам задач.
тогда за туже минуту вместо 60 документов вы будете в состоянии проиндекировать 6000.
далее, не обольщайтесь что если вы хотите индексировать только УЗ сайты, то у вас будет маленький индекс. проблема маленького сегмента - в его разрознености, вы можете проиндексировать несколько замкнутых сайтов составляющих часть этого сегмента, но это не даст вам индекса ВСЕХ сайтов.
для того чтобы проиндексировать ВСЕ УЗ сайты вам придеться переодически выходить за рамки УЗ сегмента чтобы проиндексировать более глобальные вещи и через них найти другие сегменты УЗ сайтов.
далее майСКЛ - хороший выбор для тестов, но для продакшн системы это не есть лучший вариант.
Си хороший язык и сам по себе краулер стоит писать именно на нем.
но вот систему анализа стоит делать на языке который позволит нормально обрабатывать тексты в вашей национальной кодировке и т.д (хотя некоторые в уникод предпочитают все переводить и работать с ним, но имхо это уменьшает функционал и повышает процессорное время требуемое на обработку данных).
гугл и инктоми на питоне вроде когда то делали, по мне так перл и РНР тоже для этой цели подойдут, но ресурсов очень много жрать будут.
п.с. и не пытайся сделать сразу глобальный скрипт для поиска в интернете. для начала скопируй пару сайтов локально и потренируйся на них. а то неграмотные алгоритмы реализации могут привести к печальным последствиям :)
да я знаю где искать и порядок сум которые потребуются на написание требуемых программ.
это я просто к мифу о том что можно найти грамотных программеров за 20 баксов :)
absolut, меня сейчас интересуют следущие направления:
1.нейросети
2.OCR
3.системы промышленного поиска и анализа данных в базах данных обьемом свыше 2гигабайт.
4. автоматическая обработка изображений (на низжих уровнях без использования сторонних продуктов)
все исключительно под *никсовыми системами.
если есть люди которые реально хорошо разбираются в этих вопросах - пишите в приват, с кратким резюме и расценками на работу.
