4LF

Рейтинг
20
Регистрация
25.04.2005
hi4:
Ага это отлавливается :( еще когда линкаторы появились это начали отлавливать :(
Лучше всего перекрывать... две версии сайта неудобно, яшка к редиректу хреново отнесется... иногда конечно и с редиректом в индексе, но это редкость и после письма платону, короче гемора необобратся... Лучше перекрывать флешем текст, да и все, каждому свое. Оптимизировать удобно :)
Так что если требуется сдать проект заказчику = две версии, если для самостоятельной оптимизации и продвижения то с перекрыванием...

Спасибо, значит делаем


<body>
<div style="...">слой с роликом</div>
<div style="overflow:scroll;width:800px;height:600px;">html контент</div>
</body>
hi4:
100% клоакинг. ЯваСкрипт редирект - тоже не наилучший вариант, лучше всего подгружать флеш версию в развернутом диве, передавая на флеш ролик соответствующие параметры для "отображения нужного раздела". Если не поддерживать на флеше "отображение нужного раздела", то пользователь найдет страницу в поисковике но перейдя на страницу не обнаружит необходимой информации.

Т.е. есть html страничка, но если не робот запросил её загружать ещё и флэш, размещённый в слое, перекрывающем весь сайт?

Хотя можно не делать тогда разичия между роботом и пользователем, а сделать 2 слоя на стрнице = на нижнем html контент, на верхнем (который видит пользователь) флэш ролик. Получается каждому своё (робот увидит без проблем html, пользователь флэш ролик поверх всего этого).

Я в правильном направлении? Если да, то почему бы не делать следующим образом:

<body>

<div style="display:none;">html контент</div>
флэш ролик
</body>

Это будет считаться за клоакинг?

oleksandrenko:
Я правильно понял: при индексации каждому слову соответсвуют страницы, где встречается это слово и эти страницы упорядочены по весу слова на этой странице?

да примерно так...

oleksandrenko:
при такой структуре возникнет проблема при выборке страниц при запросе из нескольких слов. Надо будет найти пересечение по множествам (страниц), которые соответствуют разным словам, а это будет сделать проще, если страницы упорядочены по индексу.

согласен это будет проще... но когда скажембудут испольщованы 2 часто употребляемых слова, после об'единения списков получится большой длины результат, который затем нужно отранжировать (что займет не мало времени)

Interitus:
По-моему слишком сложно. Существуют готовые средства для очередей, с готовыми же блокировками. Можно держать общую на весь процесс очередь заданий на скачивание, пул потоков-рабочих - которые достают задание из очереди, и выполняют, и поток-контроллер - который мониторит размер очереди, если он превышает какой-то порог - порождает новые потоки (до определенного предела), если наоборот - останавливает старые.

вот интересен этот порог... как его посчитать... (там же потом еще и индексирование будет работать...) А что за готовые средства... попобдромнее можно.?..

Interitus:
Ну Java это вообще штука сильно на любителя. Посмотрите еще в сторону python - для качальных дел неплох, да и сам по себе язык приятный очень.

про java да, согласен -)) есть повод изучить его получше...

на питон смотрел раньше чем на java, подкупает еще и тем что google на нем роботов написал -)

Cейчас crawler на perl'e. Но думаю переписывать на java (встроенная многопоточность). Схему контроля думаю сделать такой:

-у crawler_manager'a есть список сайтов

-например manager запустил на скачку 10 crawler'ов

-те начинают качать... например на главной страничке 20 ссылок... у crawler'a составляется список страниц данного сайта... crawler запускает 20 потоков (на каждую страницу 1 поток)... каждый поток отслылает crawler'y время получения страницы... crawler суммирует время от всех потоков... (хотя нет, они же параллельно работают... тогда выбирает максимум) и отпраляет это значение crawler_manager'y тот в свою очередь сравнивает показания всех 10 crawler'ов (так же еще он память должен смотреть...) и принимает решение запустить на скачку еще 1 сайт или сказать crawler'y, который больше всего времени ждет сервер, что нужно остановить поток, или вообще остановить crawler...

списки сайтов и стрниц сайтов ( + флаги ) думаю хранить в key-value БД (почитал этот форум... все говорят что юзать СУБД накладно...). нашел berkeley-db java edition...

вот только думаю не сильно-ли завернутая схема... кто какую схему применяет вообще, и стоит ли на java все это делать (почему решил java = анализ тектса + потоки + пороще С++)...

Maxim Golubev:
1. Формула расчёта веса слова в документе оперирует переменными только одного документа ? Т.е. количество данного слова в других текстах и во всей коллекции не учитывается ?

да, согласен, TF*IDF здесь проблематично использовать... (придется перегруппировывать блоки)... Мучает просто то что при запросе придется лопатить весь индекс (если брать некоторую его часть, тогда есть ли смысл индексировать N документов, если при поисковом запросе использовать только его часть)... Думаю над "пред-ранжированием"...

Maxim Golubev:
2. При нахождении объединения массивов @1, @2 ... @N результирующий массив получается размерностью < 10. Что тогда ?

while ( resn < 10 ) { getNextGroup... }

statev:
Получается, что выдача зависит сама от себя. Какой в ней смысл?

почему? поясните, плиз...

Maxim Golubev:
2. Ввести рейтинг текстов, с учётом рейтинга делать сортировку списка ID текстов, где встречается каждое слово.

рейтинг текстов = какие именно критерии учитывать при подсчете рейтинга (примеры или том где можно почитать про это)

Maxim Golubev:
В маленький индекс записывать только часть списка ID текстов.

а по каккому критерию / критериям определять вставлять ID или нет в маленький индекс?

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

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

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

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

lagif:
4LF, Вы не про те кластеры думаете...
Здсь кластер - это несколько объединенных в единую вычислительную систему компьютеров (читай: серверов). Каждый отвечает за отдельную часть индекса, и в определенный момент роутер при обращении пользователя отправляет его на менее загруженный сервер...
Примерно так.

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

123 4
Всего: 37