hi4: Ага это отлавливается :( еще когда линкаторы появились это начали отлавливать :(
Лучше всего перекрывать... две версии сайта неудобно, яшка к редиректу хреново отнесется... иногда конечно и с редиректом в индексе, но это редкость и после письма платону, короче гемора необобратся... Лучше перекрывать флешем текст, да и все, каждому свое. Оптимизировать удобно :)
Так что если требуется сдать проект заказчику = две версии, если для самостоятельной оптимизации и продвижения то с перекрыванием...
Спасибо, значит делаем
<body>
<div style="...">слой с роликом</div>
<div style="overflow:scroll;width:800px;height:600px;">html контент</div>
</body>
hi4: 100% клоакинг. ЯваСкрипт редирект - тоже не наилучший вариант, лучше всего подгружать флеш версию в развернутом диве, передавая на флеш ролик соответствующие параметры для "отображения нужного раздела". Если не поддерживать на флеше "отображение нужного раздела", то пользователь найдет страницу в поисковике но перейдя на страницу не обнаружит необходимой информации.
Т.е. есть html страничка, но если не робот запросил её загружать ещё и флэш, размещённый в слое, перекрывающем весь сайт?
Хотя можно не делать тогда разичия между роботом и пользователем, а сделать 2 слоя на стрнице = на нижнем html контент, на верхнем (который видит пользователь) флэш ролик. Получается каждому своё (робот увидит без проблем html, пользователь флэш ролик поверх всего этого).
Я в правильном направлении? Если да, то почему бы не делать следующим образом:
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: Получается, что выдача зависит сама от себя. Какой в ней смысл?
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мб/с (около того)
Ага это отлавливается :( еще когда линкаторы появились это начали отлавливать :(
Лучше всего перекрывать... две версии сайта неудобно, яшка к редиректу хреново отнесется... иногда конечно и с редиректом в индексе, но это редкость и после письма платону, короче гемора необобратся... Лучше перекрывать флешем текст, да и все, каждому свое. Оптимизировать удобно :)
Так что если требуется сдать проект заказчику = две версии, если для самостоятельной оптимизации и продвижения то с перекрыванием...
Спасибо, значит делаем
100% клоакинг. ЯваСкрипт редирект - тоже не наилучший вариант, лучше всего подгружать флеш версию в развернутом диве, передавая на флеш ролик соответствующие параметры для "отображения нужного раздела". Если не поддерживать на флеше "отображение нужного раздела", то пользователь найдет страницу в поисковике но перейдя на страницу не обнаружит необходимой информации.
Т.е. есть html страничка, но если не робот запросил её загружать ещё и флэш, размещённый в слое, перекрывающем весь сайт?
Хотя можно не делать тогда разичия между роботом и пользователем, а сделать 2 слоя на стрнице = на нижнем html контент, на верхнем (который видит пользователь) флэш ролик. Получается каждому своё (робот увидит без проблем html, пользователь флэш ролик поверх всего этого).
Я в правильном направлении? Если да, то почему бы не делать следующим образом:
Это будет считаться за клоакинг?
Я правильно понял: при индексации каждому слову соответсвуют страницы, где встречается это слово и эти страницы упорядочены по весу слова на этой странице?
да примерно так...
при такой структуре возникнет проблема при выборке страниц при запросе из нескольких слов. Надо будет найти пересечение по множествам (страниц), которые соответствуют разным словам, а это будет сделать проще, если страницы упорядочены по индексу.
согласен это будет проще... но когда скажембудут испольщованы 2 часто употребляемых слова, после об'единения списков получится большой длины результат, который затем нужно отранжировать (что займет не мало времени)
По-моему слишком сложно. Существуют готовые средства для очередей, с готовыми же блокировками. Можно держать общую на весь процесс очередь заданий на скачивание, пул потоков-рабочих - которые достают задание из очереди, и выполняют, и поток-контроллер - который мониторит размер очереди, если он превышает какой-то порог - порождает новые потоки (до определенного предела), если наоборот - останавливает старые.
вот интересен этот порог... как его посчитать... (там же потом еще и индексирование будет работать...) А что за готовые средства... попобдромнее можно.?..
Ну 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 = анализ тектса + потоки + пороще С++)...
1. Формула расчёта веса слова в документе оперирует переменными только одного документа ? Т.е. количество данного слова в других текстах и во всей коллекции не учитывается ?
да, согласен, TF*IDF здесь проблематично использовать... (придется перегруппировывать блоки)... Мучает просто то что при запросе придется лопатить весь индекс (если брать некоторую его часть, тогда есть ли смысл индексировать N документов, если при поисковом запросе использовать только его часть)... Думаю над "пред-ранжированием"...
2. При нахождении объединения массивов @1, @2 ... @N результирующий массив получается размерностью < 10. Что тогда ?
while ( resn < 10 ) { getNextGroup... }
Получается, что выдача зависит сама от себя. Какой в ней смысл?
почему? поясните, плиз...
2. Ввести рейтинг текстов, с учётом рейтинга делать сортировку списка ID текстов, где встречается каждое слово.
рейтинг текстов = какие именно критерии учитывать при подсчете рейтинга (примеры или том где можно почитать про это)
В маленький индекс записывать только часть списка ID текстов.
а по каккому критерию / критериям определять вставлять ID или нет в маленький индекс?
eshum, честно говоря про "локальный инвертированный индекс" не стал читать = но примерно понял на каждом сервере хранится часть индекса одного слова, и тогда при запросе параллельно считываются пост-листы (поэтому получается так быстро?)
а если все организовать на одном сервере (не смейтесь), то как организовать индекс?
я просто делаю на BerkeleyDB (b+tree) key это id_слова value пост-лист (пока только массив id_страниц). Например предлог "и" то мой пост-лист будет содержать столько элементов сколько проиндексировано страниц (например 1 000 000).
Этот массив нужно как-то сохранить в value (делаю на perl'e использую функцию pack и unpack; итог pack ~1сек unpack ~1сек + 1сек на считывание value), прокомментируйте/посоветуйте пожалуйста
4LF, Вы не про те кластеры думаете...
Здсь кластер - это несколько объединенных в единую вычислительную систему компьютеров (читай: серверов). Каждый отвечает за отдельную часть индекса, и в определенный момент роутер при обращении пользователя отправляет его на менее загруженный сервер...
Примерно так.
хорошо... допустим у них индекс хранится на разных серверах (то есть часть там там и там) размер считываемых данных сократится = но все равно винт читает 60мб/с (около того)