Я пытаюсь создать систему рекомендаций бедного человека для интернет-магазина. Я хочу осознать эту особенность Amazon «Покупатели, которые купили этот товар, также приобрели», и я много читаю об этом. Я знаю, что есть вещь Apache Mahout, но я не могу настроить этот сервер. Тогда был бы API прогноза Google, но он стоил денег, поэтому я начал экспериментировать сам.
Я получил orderhistory с 250.000+ пунктов, и я написал вложенный MySQL Query, чтобы найти заказы, которые содержат текущую статью, ранжировать другие элементы заказа и сортировать эту таблицу для ранжирования, поэтому я получил набор продуктов, которые другие люди заказывали вместе с текущая статья.
Проблема в том, что запрос может занимать до 10 секунд – поэтому его нельзя использовать напрямую. Я думал о таблице кеширования, но этот запрос останавливается через 20 минут (есть 60 000 продуктов и 250 000 предметов заказа). Поэтому я не могу заполнить эту таблицу.
Мое текущее решение следующее: Рекомендация HTML загружается через AJAX ondocumentready, поэтому сайт загружается, а рекомендация загружается в фоновом режиме. Данные рекомендации обрабатываются один раз и сохраняются в файловом кэше (простой кеш PEAR), поэтому он загружается быстрее в следующий раз. Таким образом, кеш создается по требованию, если кто-то посещает сайт и хранится в течение дня или, возможно, недели.
Я спрашиваю себя и вас, будет ли это приемлемым подходом или он глуп и неперспективен? Было бы лучше хранить кэшированные данные в db или в файле (я думаю о производительности и параллельных ударах). Я имею в виду, что в худшем случае я получаю 60 000 кеш-файлов.
Я бы предпочел предварительно вычисленную таблицу со всеми данными, но, как я уже сказал, это занимает много времени, и я не знаю, как ее оптимизировать. (Ожидание, когда SQL Dude вернется с праздников ^^)
Спасибо за любой намек, мнение.
Кстати. это запрос:
SELECT c.ArtNr as artnr , count(c.ArtNr) as rank, s.ArtNr as parent_artnr FROM ( SELECT a.ID_order, a.ArtNr FROM net_orderposition a WHERE a.ArtNr = 'TT-PV0005' ) s JOIN net_orderposition c WHERE s.ID_order = c.ID_order AND s.ArtNr != c.ArtNr GROUP BY c.ArtNr ORDER BY rank DESC,c.Stamp DESC LIMIT 10; РЕДАКТИРОВАТЬ:
Я думал об этих ответах, и я думаю, что они похожи на мою первоначальную идею. Приведенный выше код приводит к следующей таблице:
ID,ParentID , ChildID , Rank 1, TT-PV0005, TT-PV0040, 220 2, TT-PV0005, TT-PV0355, 135 3, TT-PV0005, TT-PV0450, 134 4, TT-PV0005, TT-PV0451, 89 5, TT-PV0005, RH-01V2 , 83 6, TT-PV0005, TT-PV0041, 83 7, TT-PV0005, TT-PV0353, 82 8, TT-PV0005, TT-PV0037, 80
Параметр ParentID – это текущий элемент, ChildID – элементы, которые были заказаны в прошлом вместе с ParentID, Rank – это предварительно вычисленное количество того, как часто ребенок упорядочивается с текущим элементом. Теперь я могу ОБНОВИТЬ или ВСТАВИТЬ связанные элементы в каждом новом порядке и подсчитывать Ранг, если он уже присутствует в БД. Единственное, чего я боюсь, я приду в действительно действительно большой таблице. Может быть, это не проблема, если я предварительно рассчитаю ее в автономном режиме раз в неделю? Но тогда я должен оптимизировать запрос, чтобы он не занимал 10 секунд на элемент.
Как вы думаете?
проверьте easyrec , у вас есть функции, которые вам нужны, и бесплатно. нет необходимости в настройке, и вы можете использовать экземпляр Demo, например google analytics. Я думаю, что будет намного проще использовать это бесплатно, чтобы использовать веб-сервис, а затем прописать всю логику самостоятельно.
В твиттере сегодня они упомянули, что они поддерживают полную поддержку mahout для easyrec, поэтому у вас есть все с easyrec.You можете либо использовать бесплатный веб-сервис easyrec, либо развернуть бесплатный WAR-файл на своем веб-сервере.
Чтобы добавить к ответу @ GalacticCowboy и заполнить, где вы комментируете, @Marcus …
Одной из схем для этого было бы создание таблицы типа:
RelatedItems RelatedItemsId purchasedItemId relatedItemId
Затем, когда заказ завершен (или просмотрен в зависимости от ваших требований), вы должны записывать записи в таблицу RelatedItems, где каждый купленный элемент получает запись, в которой этот идентификатор является приобретеннымItemId. Затем все остальные элементы будут записаны как связанныйItemId.
Например, если бы я совершил покупку предметов 5, 9, 12 и 19, у меня было бы 12 записей, которые были записаны в мою таблицу, которые выглядят так:
RelatedItemId, PurchasedItemId, RelatedItemId 1, 5, 9 2, 5, 12 3, 5, 19 4, 9, 5 5, 9, 12 6, 9, 19 7, 12, 5 8, 12, 9 9, 12, 19 10, 19, 5 11, 19, 9 12, 19, 12
Затем вы можете использовать запрос, похожий на GalacticCowboy, чтобы получить 10 лучших предметов, которые обычно покупаются рядом с любым из этих предметов.
Обратите внимание, что это не самая эффективная схема для такой задачи, ее можно было бы немного изменить, чтобы уменьшить избыточные данные, но учитывая, что мы не знаем много о вашей системе и общем дизайне схемы (и что кажется шаткое понимание некоторых концепций SQL). Я не буду углубляться в это.
Каждый раз, когда есть заказ, храните запись отношений между разными элементами в заказе. Затем сделайте что-нибудь вроде:
SELECT ItemID, COUNT(RelatedItemID) AS RelatedItemCount FROM RelatedItems WHERE RelatedItemID = @viewingItemID GROUP BY ItemID ORDER BY RelatedItemCount DESC LIMIT 10
Вы также можете предварять это с помощью ночного процесса или чего-то еще и иметь таблицу, которая содержит только элементы, относящиеся к первому n для каждого элемента.