Electra: Вроде не плохой счетчик....
бесплатный и все данные фиксирует...но тока не более чем на месяц...
и с рамблера плохо цепляет фразы
WarLog написан более почти два года назад и с тех пор практически не поддерживается. Я, как его автор, уже около года не захожу на сервер где он установлен. Проект в свободном плавании.
Как писал Kurt Мне например ну совсем не нравится как CNStats регистрирует заходы ботов. Расхождение с логами заметное.
И ботов скрипт очень мало знает.
Это каких ботов CNStats не знает ? Во первых их можно добавить самому, а во вторых, можно скинуть авторам и они добавят их сами.
Апорт добавили в течении 4-ех часов. А 600 руб. за такую систему - не деньги. Стыдно у своих воровать.
Я бы не стал безкомпромиссно заявлять что лучше использовать HTTP 1.1, так как, если робот работает только с HTTP 1.0, то страницы возвращаемые с помощью HTTP 1.1 ему не обработать.
Но зато, если робот поддерживает HTTP 1.1 то он сможет работать как с HTTP 1.1 так и с более ранними версиями протокола.
Правильно было сказано - изменять заголовок нельзя, от этого содержимое никак не изменится. Если вы вставляет в заголовок HTTP/1.0, то должны быть уверены, что данные, которые пойдут после него, соответствуют этому протоколу.
Я заметил только одно отличие между 1.0 и 1.1 - Chunked Encoding.
Как писал NataL File 'c:\mysql\share\charsets\?.conf' not found (Errcode: 22)
Character set '#14' is not a compiled character set and is not specified in the 'c:\mysql\share\charsets\Index' file
Как писал Gray Ошибаетесь. Всего в серверном зале - 160. Под роботами - 7, под поиском - 30.
Так оказывается на яндексе только 23% серверов заняты поиском ?? Остальные это народ, почта и тестовые сервера?? Так вроде получается.
Но что-то отошли от темы.
Я тоже не думаю, что при поиске используются какие-то стандартные SQL сервера, но думаю, что некоторое подобие их есть, но очень специфическое, так что сервером баз данных, в привычном для людей виде, их вряд-ли назвать можно.
Но они несомненно нужны, как-раз для кластеризации, кэширования, на относительно низком уровне, борьбе с коллизиями и подобным вещам,
Как писал iseg Вопрос в том сколько их. Если "найдена" тысяча, и вы делаете сервис для людей, а не для автомата, то по ИЛИ искать не нужно.
А если запрос таков: "а не пойти ли намс погулять."
а, не, ли - стоп слова, остается "пойти намс погулять"
слово "намс" - не найдено, хотелось бы вывести то что найдено по запросу "пойти погулять" (с припиской, что слово "намс" не найдено вообще, и результат не совсем соответсвует запросу.)
Вижу следующее решение - искать по ИЛИ, потом релевантность (число от 1 до 65535) считать, как количество_найденых_слов<<16+релевантность
Таким образом будут выведены сначала результаты в которых содержаться все слова из запроса, потом в котором не хватает одного, потом двух и т.п.
Как писал Gray mikek, может, я, конечно, глупость скажу, но что мешает искать по базе параллельно - и для "И", и для "ИЛИ", потом выбросить дубликаты и прицепить второй список в хвост первому?
Написать можно как угодно, вопрос в производительности.
1. Описание документа на данном этапе это его идентификатор: число размером в 4 байта.
2. Массивы предварительно упорядочены по идентификаторам документов, поэтому просматриваются последовательно и один раз
Что-то я не совсем понимаю, если массив упорядочен по идентификаторам документов, а результат необходимо отсортировать по релевантности, то нам все равно придется сливать их вместе целиком. После чего как-то узнавать релевантность и сортировать.
4. Основное итерирование должно идти по более короткому массиву, тогда большие куски можно будет "перепрыгивать, не читая" ("zig-zag joins" - что такое было на предпоследнем sigir, но саму статью не читал, так что может она и не про это :))
Это, я так понимаю, только для логики "И", и не подходит, если нам надо найти документ содержащий хотя-бы одно поисковое слово из фразы.
Вроде не плохой счетчик....
бесплатный и все данные фиксирует...но тока не более чем на месяц...
и с рамблера плохо цепляет фразы
WarLog написан более почти два года назад и с тех пор практически не поддерживается. Я, как его автор, уже около года не захожу на сервер где он установлен. Проект в свободном плавании.
Мне например ну совсем не нравится как CNStats регистрирует заходы ботов. Расхождение с логами заметное.
И ботов скрипт очень мало знает.
Это каких ботов CNStats не знает ? Во первых их можно добавить самому, а во вторых, можно скинуть авторам и они добавят их сами.
Апорт добавили в течении 4-ех часов. А 600 руб. за такую систему - не деньги. Стыдно у своих воровать.
Я бы не стал безкомпромиссно заявлять что лучше использовать HTTP 1.1, так как, если робот работает только с HTTP 1.0, то страницы возвращаемые с помощью HTTP 1.1 ему не обработать.
Но зато, если робот поддерживает HTTP 1.1 то он сможет работать как с HTTP 1.1 так и с более ранними версиями протокола.
Правильно было сказано - изменять заголовок нельзя, от этого содержимое никак не изменится. Если вы вставляет в заголовок HTTP/1.0, то должны быть уверены, что данные, которые пойдут после него, соответствуют этому протоколу.
Я заметил только одно отличие между 1.0 и 1.1 - Chunked Encoding.
File 'c:\mysql\share\charsets\?.conf' not found (Errcode: 22)
Character set '#14' is not a compiled character set and is not specified in the 'c:\mysql\share\charsets\Index' file
Сообщений MySql не должно быть в HTTP заголовке.
хех :)
Ошибаетесь. Всего в серверном зале - 160. Под роботами - 7, под поиском - 30.
Так оказывается на яндексе только 23% серверов заняты поиском ?? Остальные это народ, почта и тестовые сервера?? Так вроде получается.
Но что-то отошли от темы.
Я тоже не думаю, что при поиске используются какие-то стандартные SQL сервера, но думаю, что некоторое подобие их есть, но очень специфическое, так что сервером баз данных, в привычном для людей виде, их вряд-ли назвать можно.
Но они несомненно нужны, как-раз для кластеризации, кэширования, на относительно низком уровне, борьбе с коллизиями и подобным вещам,
Вопрос в том сколько их. Если "найдена" тысяча, и вы делаете сервис для людей, а не для автомата, то по ИЛИ искать не нужно.
А если запрос таков: "а не пойти ли намс погулять."
а, не, ли - стоп слова, остается "пойти намс погулять"
слово "намс" - не найдено, хотелось бы вывести то что найдено по запросу "пойти погулять" (с припиской, что слово "намс" не найдено вообще, и результат не совсем соответсвует запросу.)
Вижу следующее решение - искать по ИЛИ, потом релевантность (число от 1 до 65535) считать, как количество_найденых_слов<<16+релевантность
Таким образом будут выведены сначала результаты в которых содержаться все слова из запроса, потом в котором не хватает одного, потом двух и т.п.
mikek, может, я, конечно, глупость скажу, но что мешает искать по базе параллельно - и для "И", и для "ИЛИ", потом выбросить дубликаты и прицепить второй список в хвост первому?
Написать можно как угодно, вопрос в производительности.
Слово "А" встречается в 1 миллионе документов. Слово "Б" в другом миллионе.
Спасибо, я понял. Этот вариант мне не подходит, хотелось бы сначала выводить результаты по "И", в потом по "ИЛИ" (с подписью "нестрого соответсвие").
И еще один вопрос, что принято делать с &nbsp;, &lt, &gt;, &raquo;, &laquo;, &amp; и подобными словами ?
Ранжирование и фильтрация - разные процессы. Отфильтрованный массив - маленький.
А можно в этом месте по подробнее?? Что такое фильтрация и как она призводится ?
1. Описание документа на данном этапе это его идентификатор: число размером в 4 байта.
2. Массивы предварительно упорядочены по идентификаторам документов, поэтому просматриваются последовательно и один раз
Что-то я не совсем понимаю, если массив упорядочен по идентификаторам документов, а результат необходимо отсортировать по релевантности, то нам все равно придется сливать их вместе целиком. После чего как-то узнавать релевантность и сортировать.
4. Основное итерирование должно идти по более короткому массиву, тогда большие куски можно будет "перепрыгивать, не читая" ("zig-zag joins" - что такое было на предпоследнем sigir, но саму статью не читал, так что может она и не про это :))
Это, я так понимаю, только для логики "И", и не подходит, если нам надо найти документ содержащий хотя-бы одно поисковое слово из фразы.