ParserPro

Очень часто в процессе парсинга информации наши скрипты циклически проходят набор каких-либо урлов.

Если парсинг идет с одного источника с изменением, например, некоторых GET или POST параметров, то в любую единицу времени вы можете точно определить месторасположение своего скрипта. Но бывают случаи когда массив урлов собирается, например, с поисковика. И все было бы хорошо, если бы человек не придумал такую штуку как редирект и если бы ваш заказчик не требовал заносить УРЛ конечной страницы в базу данных.

А можете ли вы однозначно утверждать, что урл, который вы достали из выдачи Гугла однозначно равен урлу, на который зашел ваш скрипт и на котором он производил поиск информации? Если вы говорите “ДА”, то вы сильно ошибаетесь. Можете попробовать поэкспериментировать с такими запросами к Google как “Viagra” - половина сайтов будут либо дорвеями, либо прочими видами редиректеров.

И, поверьте, это всего лишь одна из ситуаций, когда в процессе парсинга/граббинга надо точно определять урл страницы, на которой находится ваш скрипт.

В качестве других типичных примеров можно привести сборы урлов из каталогов компаниий или каталогов галерей картинок. Как часто вы видите подобные урлы: http://www.site.com/redirect.php?id=700? Понятное дело, что подобное записывать в поле URL в своей базе просто стыдно :), потому что через пару часов вы уже не сможете гарантировать, что вышеуказанная ссылка будет ссылаться на тот сайт, на котором вы произвели поиск информации.

Я столкнулся с подобной проблемой при работе над одним проектом по сбору картинок с галерей изображений. Редиректеры вытворяли что-то нереальное: одна и таже ссылка на редиректере вела на разные сайты. И даже не надо было ждать пару часов - это происходило ежесекундно!

И это бы ничего, ведь даже file() умеет следовать редиректам. Но ведь заказчик потребовал в базе в отдельное поле писать конечный URL…

Решить данную проблему можно достаточно просто и вариантов ее решение есть несколько.

Самым разумным и быстрым из них будет использование функции curl_getinfo. И вообще я бы советовал всем программистам, которые используют библиотеку curl присмотреться к этой функции, ведь бывают ситуации, когда она может быть очень полезной.

Вот типичный пример использования данной функции в одном из моих классов:

function GetLastURL() {
	return curl_getinfo($this->curl_handler, CURLINFO_EFFECTIVE_URL);
}

В результате использования данной незатейливой функции вы получите последний урл, куда был перенаправлен ваш скрипт.

А что же делать, если вы не пользуетесь функционалом curl’a, а используете, например, file_get_contents()? Тогда прийдется немного поиграться в функцией stream_get_meta_data(). Вот типичное решение, которое я использовал в одном из своих проектов, где по ТЗ нельзя было использовать CURL:

$content = file_get_contents($url);
$fp = fopen($url,'r');
$meta_data = stream_get_meta_data($fp);
foreach($meta_data['wrapper_data'] as $response) {
	if (substr(strtolower($response), 0, 10) == 'location: ') {
		$last_url = substr($response, 10);
	}
}
fclose($fp);

Из данного кода я убрал все проверки и прочие функции, которые не имеют непосредственного отношения к обсуждаемой теме.

Как мы видим второе решение намного более громоздкое по количеству написанного кода, да и ограничений у него побольше будет. Но тем не менее каждый из вышеуказанных вариантов имеет право на жизнь.

Пользуйтесь ими на здоровье в своих парсерах, грабберах и анализаторах и не никогда не теряйтесь!

Наконец-то удалось немного разгрести гору заказов и написать.

На прошлой неделе очень интересно получилось с моим тестом-сравнением скорости работы preg_replace() и str_replace(). Я провел измерения, результаты были вполне предсказуемые, но YS.PRO подкинул новый опыт, по результатам которого скорость str_replace() превысила preg_replace() в 24 раза! Конечно, это больше чем я ожидал, хотя также вполне прогнозируемо.

И после этого у меня было четкое намерение провести последний тест, в котором я хотел циклично применять вышеуказанные функции к разному контенту, но сейчас я решил отказаться от этой затеи, четко понимая, что результат останется в том же диапазоне, а я потрачу свое время.

Поэтому пока никаких больше тестов. Надо завершить все проекты, подготовиться к Новому Году и уехать куда-то отдыхать!

В связи с этим я хочу проинформировать моих заказчиков, что до Нового Года у меня осталось всего 2 места в моем проджект лайне и более я, к сожалению, буду не в силах выполнить. Поэтому если кто-то затеял сделать что-то гениальное, то стучитесь прямо сейчас, потому что через пару дней уже будет поздно.

На этом все. Удаляюсь. В следующих постах обещаю рассказать об интересных функциях curl и умном взвешивании результатов при сборе картинок.

Удачи!

Недавно к моему посту “Парсинг выдачи Google. Практика.” [YS.PRO] оставил коммент следующего содержания:

$Result=preg_replace(”/[\n\r\t]/”, ”, $Result);

Ох не нравится мне это, зачем комп мучать?
$result = str_replace(array(”\n”, “\r”, “\t”), ”, $result);

Конечно же сомневаться в том, что на данной операции str_replace() быстрее мне не приходится, но мне все-таки захотелось протестировать разницу в скорости при использовании этих двух функций.

Начальные условия:

• PHP 5
• Apache 2
• Параллельно запущено 4 громадных скрипта, которые уже проработали 3е суток, так что определенную погрешность из-за них можно ожидать

Тестирование производилось при помощи следующего кода.
Код №1

<?php 
require_once 'timer.class.php';
 
$text="Почему я делаю это?\r\nНе знаю, но это весело!\r\nВедь надо же стать легендой )";
echo $text;
 
$timer=new Timer();
$timer->start();
$Result=preg_replace("/[nrt]/",'', $text);
$point=$timer->stop();
echo $point;
 
if($fh=fopen('preg.txt','a')) {
	fwrite($fh,$point."\r\n");
	fclose($fh);
} else {
	echo 'Вечная ошибка с файловой системой!';
}
 
?>

Код №2

<?php 
require_once 'timer.class.php';
 
$text="Почему я делаю это?\r\nНе знаю, но это весело!\r\nВедь надо же стать легендой )";
echo $text;
 
$timer=new Timer();
$timer->start();
$result = str_replace(array("n", "r", "t"), '', $text);
$point=$timer->stop();
echo $point;
 
if($fh=fopen('str.txt','a')) {
	fwrite($fh,$point."\r\n");
	fclose($fh);
} else {
	echo 'Вечная ошибка с файловой системой!';
}
 
?>

Класс Timer имеет следующий вид:

<?php 
 
 class Timer
 {
 	var $timers		= array();
 	var $precision	= '';
 
 	function Timer($prec=6)
 	{
 		$this->precision=$prec;
 	}
 
 	function get_precision()
 	{
 		return $this->precision;
 	}
 
 	function set_precision($new_precision)
 	{
 		$this->precision=$new_precision;
 	}
 
 	function _getmicrotime() 
 	{
 		list($msec,$sec)=explode(" ",microtime());
 		return ($sec.substr($msec,1));
 	}
 
 	function start($timer='def')
 	{
 		$this->timers[$timer]=$this->_getmicrotime();
 		return true;
 	}
 
 	function stop($timer='def')
 	{
 		if(!array_key_exists($timer,$this->timers)) return false;
 		return round($this->_getmicrotime()-$this->timers[$timer],$this->precision);
 	}
 } 
?>

В результате тестирования были получены следующие результаты для preg_replace():
6.6E-5
0.212309
0.212233
-1.0E-6
-1.0E-6
-1.0E-6
0.000571
0.000126
0.000132
0.000443
И как результат среднее время: 0.0425877 секунд.

В свою очередь для str_replace() были получены такие результаты:
4.0E-5
4.2E-5
-1.0E-6
-2.0E-6
-1.0E-6
0.000291
0.212443
0.000484
0.000212
-1.0E-6
И как результат среднее время: 0.0213507 секунд.

Среднее время измерялось при помощи следующего скрипта:

 
$nums1=@file('str.txt');
$nums2=@file('preg.txt');
$sum1=0;
$sum2=0;
foreach ($nums1 as $num) {
	$sum1+=$num;
}
foreach ($nums2 as $num) {
	$sum2+=$num;
}
 
echo 'str:',round($sum1/10,12)."\r\n";
echo 'preg:',round($sum2/10,12)."\r\n";
?>

Выводы:
1. Для операции операции по скипу вайтспейсес лучше использовать str_replace, так как он в 2 раза быстрее аналогичного синтаксиса с preg_replace.
2. Так как операция по скипу вайтспейсов чаще всего проводиться 1 раз на цикл (или лучше сказать, один раз на этап обработки конечной страницы), то временем задержки в 0,02 секунды можно пренебречь как незначительным.

ЗЫ. Данные тестирования я считаю важными, так как они помогают максимально оптимизировать используемые механизмы для достижения наивысшим результатов. Поэтому в дальнейшем я постараюсь их проводить как можно чаще!

Главным оружием любого профессионального парсера являются регулярные выражение (особенно перловые PCRE). И я, если честно, вообще не представляю как без них можно делать просто и быстро свою работу.

Одним словом просто прелесть. И эту прелесть мы каждый день используем.

Сечас я приведу 2 классических варианта использования регулярных выражений:

if (preg_match("/$price_find/Ui",$content,$m)) {
        unset($m[0]);
	$price=mysql_escape_string(trim($m[1]));
} else {
        $price='';
}
 
if (preg_match_all("/$blocks_find/Ui",$content,$m)) {
	unset($m[0]);
        $blocks=$m[1];
} else {
        $blocks=array();
}

На первый взгляд довольно таки простой код. Ни отнять, ни прибавить. А теперь представьте, что вам надо искать по 100 параметров на странице. И тогда этот код начнет непомерно расти и станет для вас настоящим наказанием. В подобных случаях я использую две небольшие функции, которые действительно упрощают мне жизнь и уменьшают время, затрачиваемое на разработку:

function pregm($what, $where, $return=1, $keys='Ui') {
	$search="/$what/$keys";
	if (preg_match($search,$where,$matches)) {
		unset($matches[0]);
		if ($return==1) {
			return $matches[1];
		} else {
			return $matches;
		}
	} else {
		return false;
	}
}
 
function pregma($what, $where, $return=1, $keys='Ui') {
	$search="/$what/$keys";
	if (preg_match_all($search,$where,$matches)) {
		unset($matches[0]);
		if ($return==1) {
			return $matches[1];
		} else {
			return $matches;
		}
	} else {
		return false;
	}
}

Благодаря этим функциям весь начальный код можно преобразовать к следующему виду:

$price=mysql_escape_string(trim(pregm($price_find,$content));
$blocks=pregma($blocks_find,$content);

Вот так все просто. Мы сократили объем кода в несколько раз и сделали его более прозрачным и простым.

Конечно же если регулярные выражения вы используете два раза в год, то прибегать к данной библиотеке нет смысла, но если регулярки - ваша повседневная работа, то вам надо максимально использовать вышеупомянутый код и даже развить его под свои нужны. Так я, например, в случаях, когда надо найти большое количество параметров, использую массивы. Вот пример:

$param=array(
'Название',
'Цена',
'Размер',
'Автор'
//...
);
 
$find=array();
 
// Получаем контент и делаем прочие преобразования
 
foreach ($param as $key=>$item) {
	$find_it=$item."\:(.*)$";					
        $find[$key]=strip_tags(pregm($find_it,$block));
}

Получится, что в массиве $find у нас будут все найденные параметры. Потом можно просто сделать implode("','",$find), добавить пару кавычек и практически целиком залить эту строку в базу. Получается очень быстро и удобно.

Суть этой заметки. Регулярные выражения - мощный инструмент, а свои надстройки над ними - еще более мощный и удобный инструмент!

На днях закончил проверку новой системы GrabVIA для сбора изображений, аудио- и видеоконтента.

В течении двух суток данной системой было собрано 194 766 изображение суммарным размером около 5 ГБ.

Так что я думаю, что система вполне работоспособная и готова к выполнению даже самых сложных заданий.

Ребята, я вас очень прошу не пытаться взломать мой сайт, потому что ничего интересного на нем, даже если вы его сломаете, не найдете. На этом хостинге я свой движок не держу. Тут только блог.

Это относится к тем, кто вчера целый день в комментах писал подобные вещи:

“>alert(’xss’)

В последнее время я заметил, что очень многим заказчикам необходим сбор большого объема изображений, аудио- и видеоконтента. Поэтому я решил выделить данный вид работы в отдельную услугу.

Спецификой работы по сбору подобного контента является то, что БД имеет второстепенное значение, в то время как выдвигаются дополнительные требования к дисковой системе и скорости интернет-канала. Все эти особенности учтены в разработанной мной системе GrabVIA, предназначенной ИСКЛЮЧИТЕЛЬНО для сбора вышеуказанного контента.

ТТХ услуги:

• 2 сервера (для очень крупных заказов возможно выделение до 4 серверов);
• неограниченное время сбора информации (24/7/365);
• сбор информации блоками до 100 Гб (100 Гб собрали -> отгрузили заказчику -> приступили к сбору очередных 100 Гб).

В качестве входных параметров для начала предоставления данной услуги могут выступать:

• текстовый файл с адресами файлов для скачивания;
• парсинг страниц для нахождения контента для скачивания.

Также возможна автоматизация работы:

• вы даете мне параметры для доступа к FTP и весь собранный контент, с указанной вами регулярностью, синхронизируется с вашим сервером (также возможно настроить синхронизацию БД, если попутно со сбором контента будет собираться какая-то информация или параметры).

За прошедшие несколько месяцев парсинг, граббинг и сбор информации показали себя как достаточно актуальные и востребованные услуги на современном рынке IT-услуг.

В связи с этим я хочу еще более расширить список клиентов компании ParserPro и в качестве первого шага на этом нелегком пути я представляю партнерскую программу.

С сегодняшнего дня в нашей компании действует партнерская программа на следующих условиях:

1. За каждого приведенного мне клиента участник партнерской программы получает 20% от стоимости заказа клиента.
2. Если участник партнерской программы привел более 5 клиентов, то он получает 25% от стоимости заказа с каждого последующего заказа.

Для регистрации в партнерской программе вы должны отписать мне на ICQ, либо на емейл (смотрите контакты), либо оставить комментарий к данному посту. От вас требуются следующие данные: ФИО, контактные данные.

Вот так все просто. Вы приводите заказчиков для нашей компании и зарабатываете деньги!

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

230 000 записей!

База собиралась изначально в 2 потока, а потом в 5 в течении 3х дней. В процессе работы над этим заказом я понял:

• Что мне нужно купить новый компьютер (что я уже удачно и сделал);
• Что для каждого проекта нужно писать контроллер процесса выполнения, чтобы случайная остановка сайта-источника на пару часов не останавливала процесс сбора информации и не привела к искривлению данных в базе;
• Что в php memory_limit нужно ставить в значение 64М и постоянно вести мониторинг ресурсов, а то кто бы что не говорил, но php “течет” и это факт, доказанный практикой;
• Что нужно проводить оптимизацию регулярных выражений (этому я думаю посвятить отдельную статью).

Думаю, что некоторые из этих мыслей могут быть полезны другим про в области сбора информации.

Особенно важным моментом является контроль процесса выполнения. В каждом конкретном случае его можно реализовать по разному и я вот сейчас работаю над созданием универсального класса. Как только будут первые наработки - я сразу же отпишу про это в очередной заметке.

В данной заметке я хочу затронуть вопрос нахождения и удаления дублирующихся записей в MySQL.

И это касается не только вопроса сбора информации. Предлагаемые методы будут очень полезны начинающих программистам, которые ищут оптимальное решение в данном вопросе.

Для того, чтобы было проще объяснять код я создам тестовую таблицу work с ней буду производить свои эксперименты.

Таблица work имеет следующую структуру:

CREATE TABLE work( 
 id mediumint(8) UNSIGNED NOT NULL AUTO_INCREMENT, 
 region varchar(255) NOT NULL, 
 job_mask varchar(255) NOT NULL, 
 job_group varchar(255) NOT NULL, 
 job_info text, 
 PRIMARY KEY(id));

Вдаваться в тонкости создания таблиц мы не будем, так как это не является целью данной статьи.

Предположим, что таблица work уже заполнена данными.

Теперь вам надо оставить в таблице только уникальные данные в поле job_info для каждого значения region, job_group, job_mask.

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

SELECT COUNT(*) AS dub, region, job_group, job_mask, job_info 
FROM work GROUP BY region, job_group, job_mask, job_info HAVING dub>1;

В результате выполнения запроса вы увидите таблицу с уже знакомыми вам полями и с дополнительным полем dub, которое будет содержать количество дублирующихся записей.

Далее удаление можно организовать следующими путями:

1. Циклический обход-1.
   Данный метод я называю “циклический обход-1″, потому что одну запись мы всегда оставляем не тронутой.

   Реализуется данные метод следующим способом:

    
    // соединение с БД  
    
    $query='SELECT COUNT(*) AS dub, region, job_group, job_mask, job_info 
    FROM work GROUP BY region, job_group, job_mask, job_info HAVING dub>1'; 
    $res=$db->query($query); 
    if(!$res) { 
   	echo $db->error(); 
    } else { 
   	while($row=$db->fetchAssoc($res)) { 
   	        $region=$row['region']; 
     	        $job_mask=$row['job_mask']; 
     	        $job_group=$row['job_group']; 
   	        $job_info=$row['job_info']; 
    
   	        $query="SELECT id FROM work 
   WHERE region='$region' AND job_mask='$job_mask' 
   AND job_group='$job_group' AND job_info='$job_info'"; 
    
   		$result=$db->query($query); 
   		if(!$result) { 
   			echo $db->error(); 
   		} else { 
   			$i=1; 
   			while ($subrow=$db->fetchArray($result)) { 
   				if ($i==1) { 
   				    $i++; 
   				    continue; 
   				} 
    
   				$query="DELETE FROM work 
                                                WHERE id='{$subrow[0]}'"; 
   				$del_res=$db->query($query); 
   				if(!$del_res) { 
   					echo $db->error(); 
   				} else { 
   					$deleted++; 
   				} 
   				$i++; 
   			} 
   		} 
   	} 
   }

   Методы объекта $db, которые используются по ходу выполнения скрипта, являются методами моего стандартного абстрактного класса для доступа к БД. Имена методов очень тесно переплетаются с именами стандартных функций для работы с MySQL, поэтому я не вижу смысла останавливаться на этом более детально.

   В своих скриптах вы можете использовать привычные вам инструменты.

   Главным преимуществом данного решения есть простота. Однако есть и очень большой недостаток - низкая скорость выполнения. На больших таблицах с большим количеством записей данный скрипт будет выполняться очень долго. Так что не забудьте поставить лимит времени и лимит памяти побольше.

2. Использование запроса SELECT.
   Второй вариант решения поставленной проблемы также достаточно распространен и предполагает некоторые знания в области SQL.Далее я приведу несколько запросов направленных на удаление дублирующихся записей и дам детальное их описание.

   Выборка уникальных данных в отдельную таблицу. Реализуется данный метод следующим образом:

    CREATE TABLE original 
    SELECT DISTINCT * FROM work ORDER BY id;

   Данный запрос создаст таблицу original с оригинальными значениями, выбранными из таблицы work.

   Также можно использовать следующую модификацию вышеуказанного выражения:

    CREATE TABLE original 
    SELECT * FROM work GROUP BY region, job_group, job_mask, job_info 
    ORDER BY id;

Дополнительная информация:

• Скачать исходника абстрактного класса DB

P.S. Думаю, что для начала этого инструментария будет достаточно. Но я не оставляю данную тему и надеюсь в ближайшем будущем предоставить дополнительную информацию по обработке дублирующихся записей в MySQL.