PHP MYSQL в XML - Эффективная генерация файлов

Question

У меня работает механизм сравнения цен, и, поскольку мы собираем так много данных, у меня возникают довольно серьезные проблемы с производительностью. Мы генерируем различные XML-файлы, по одному для каждого продукта, и в данных о продукте каждый Интернет-магазин, из которого мы получаем данные, с указанием цены, ссылки, описания и т. Д.

У нас есть несколько парсеров / скребков, которые собирают информацию о ценах для каждого продукта. Данные о продукте загружаются в базу данных MySQL, затем файл PHP размещается на сервере и генерирует XML для каждого продукта.

Проблема, с которой мы сталкиваемся, заключается в том, что для 10000 продуктов генерация XML занимает почти 25 минут! БД полностью нормализована, и я создаю XML через PHP Dom.

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

Использую ли я систему флагов? Но разве это не приводит к большему количеству просмотров базы данных, которые могут увеличить издержки базы данных? Текущие запросы занимают всего ~ 0,1 секунды для каждого продукта.

Кроме того, что произойдет, если в XML-файле изменится только 1 цена за 1 магазин, из-за этого кажется, что перезаписывать весь файл снова напрасно, но, конечно, preg_replace будет таким же трудоемким?

Спасибо за ваше время, очень признателен!

Answer 1

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

Всякий раз, когда я могу сделать имя файла на сервере хешем MD5, мне приходится выполнять еще меньше работы с сервером - я просто сравниваю имя файла с хэшем БД.

Что касается внутреннего обновления, вам, вероятно, потребуется использовать какой-то тип REGEX, но вы будете выполнять замену реже, поскольку будете знать, когда что-то изменится в файле.

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

EDIT:

При перечитывании вашего поста звучит так, будто вы хэшируете данные со своих скребков для сравнения с БД. Все та же основная идея, но я хотел уточнить, что я думаю, что она все еще будет работать. Затраты на выполнение запроса должны быть еще более легкими, поскольку вы могли бы извлечь только 32 символа из БД в очень специфическом запросе - при правильно настроенных индексах это должно быть ОЧЕНЬ быстро.

Кроме того, хотя я никогда не использовал его - посмотрите на что-то вроде simplexml , которое встроено в PHP - это может дать вам быстрый и простой способ изменения данных в правильно сформированном XML без необходимости используйте REGEX и напишите это самостоятельно.

Answer 2

10000 файлов, записанных за 25 минут, - это около 6 файлов в секунду. Даже если ваш HD может поддерживать xGB / sec, вы не можете записывать X гигабайт данных в секунду в нескольких файлах, но при создании нового файла в индексе FAT возникают дополнительные затраты.

Имхо, основная проблема в том, что вы имеете дело со статическими файлами, что является плохим выбором с точки зрения вашей производительности. Самое разумное решение - перестать использовать эти статические файлы, поскольку они, очевидно, не работают так же хорошо, как запросы к базе данных. Если что-то непосредственно анализирует эти файлы, возможно, вам следует использовать MOD_REWRITE для Apache, и вместо записи реальных файлов XML, URL-адрес должен выполнить живой запрос к базе данных и вывести файл по запросу. Таким образом, вам не нужно вручную создавать все файлы XML.

Но если вы продолжите использовать этот неоптимальный метод, вам придется создать для этого отдельный выделенный сервер / хранилище. Вы случайно не размещаете базу данных и веб-сервер на одном компьютере? Если это так, вы должны разделить их. Вам может понадобиться отдельный сервер или NAS для хранения этих файлов XML, возможно, в высокопроизводительной установке raid 0.

Таким образом, я очень сомневаюсь, что ваша база данных является узким местом, это акт сохранения всех этих крошечных файлов.

Answer 3

preg_replace будет намного хуже. Возможно, вы захотите перейти от DOMDocument к SimpleXML, который, как мне кажется, требует меньше накладных расходов, но в то же время, если вам нужно удалить узлы, вам придется добавить DOMDocument в смесь, чтобы сохранить здравомыслие.

Я также поддержал предложение Шейна о сравнении хэшей из очищенных данных с данными из БД. Кажется, это хороший способ отсеять изменения, после чего вы можете обрабатывать их с помощью выбранной вами библиотеки DOM.