Обычно помогает 2 вещи:
1. Напомнить хостеру, что в случае подачи заявления и начала судебного разбирательства скорее всего "техническое обеспечение" будет изьято для проведения следственных действий.
2. Написать регистратору домена (и по восходящей) с просьбой проверить валидность контактов домена (конечно обьяснить, что вот, своровали а вы связаться не можете...)
О, собирали из исходников с SF?
Как минимум - "правильный" UserAgent. И еще неплохо бы плюсовые баллы давать словам в тайтле, H1, H2, ..., strong 🙄
Только если научиться фильровать "постоянные" блоки на сайте (меню, например).
Это говорит только о том, что с данной тематикой пока никто не сталкивался :)
Обучить его - дело пары минут. ;)
Очень даже приятная штука.
Сразу пару вопросов:
1. Что юзаете для морфологии?
2. Ковырять в сторону словосочетаний из 2-х, 3-х слов не пробовали?
3. Разбирается ли текст страницы "с точки зрения бота"?
4. Смотрели на функционал http://extheme.ru/ ? Есть планы по реализации подобного?
Спору нет. Только там INSERT ... ON DUPLICATE KEY UPDATE ;)
SELECT * FROM `urls` WHERE k <=0.8 and url = '1' ORDER BY k DESC LIMIT 1
Ясное дело, что 0.8 мне ГСЧ отдал.
CREATE TABLE IF NOT EXISTS `urls` ( `url` varchar(255) NOT NULL, `keyword` varchar(50) NOT NULL, `cnt` int(10) NOT NULL default '1', `k` decimal(10,4) NOT NULL default '0.0000', UNIQUE KEY `index` (`url`,`keyword`), KEY `url` (`url`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; CREATE TABLE IF NOT EXISTS `sums` ( `url` varchar(255) NOT NULL, `sm` int(10) NOT NULL, UNIQUE KEY `url` (`url`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
Как считается и апдейтится k из таблицы urls обьяснять думаю не надо ;)
Ой, прям в разы? ;) К тому же, это вызываться будет ой как не часто.
Не совсем понял, зачем.
Вы так уверенно бравировали знаниями SQL в топике, что я как-то упустил вероятность того, что вы не догадаетесь что вывод списка запросов + вероятность его выбрать сделана для демонстрации. В реальности - любимым генератором случайных чисел получили значение от 0 до 1 и выбрали тот 1 запрос, вероятность которого ближе всего к полученному значению.
Играюсь сейчас с парой табличек, занятные результаты.
Поскольку запрашивать данные (SELECT) тут приходится намного чаще, чем обновлять (UPDATE/INSERT), то:
1) храним в БД: урл странцы, ключ перехода с ПС, количество переходов
2) при переходе с ПС:
INSERT INTO table (url,key,cnt) VALUES ($url,$key,1) ON DUPLICATE KEY UPDATE c=c+1;
3) при выборе ключа для страницы:
select key, (cnt / (select sum(t1.cnt) from table t1 where t1.url = t2.url)) * 100 as prfrom table t2where t2.url = '$url'order by pr desc
Понятное дело, что вместо подзапроса имеет смысл сумму сразу получать и потом делить на константу во втором запросе. Или даже при апдейте table обновлять в другой таблице (url, sum_cnt) сумму - тогда еще проще.
Но даже без оптимизаций у меня на таблице с 10000 записями никаких тормозов не возникло.
Если не так срочно, что на вчера - то вечером быстренько соберу и отправлю.
Вы уточните вначале, что для вас "качественный контент" и "массовость".
А то может мы говорим о плохо распознаном скане и 5к символов в день :)
Хотел уточнить - кому известно?
Мне например известно из RFC, что ссылки прописываются английскими буквами. И все.
То, что часть браузеров при определенных настройках умеет автоматом конвертить юникод-ссылки (на руском) в их XN представление - это конечно здорово, но... RFC как-бы первичен.
И? В настройках вебсервера указывается чем обрабатывать определенные расширения.
Так что никто не мешает в файлы с расширением php записывать ASP VBscript и обрабатывать на сервере как ASP. И наоборот.
IIS последних версий отлично справляются, например.
