mahout-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: Memory and Speed Questions for Item-Based-Recommender
Date Mon, 13 Jul 2009 11:16:48 GMT
I think Ted's suggestion is you'll find Lucene will be _a lot faster_  
for this task as you don't need all the other trappings of a DB.

On Jul 13, 2009, at 4:36 AM, Sean Owen wrote:

> How does Lucene go from item-item links to recommendations? I'm
> missing where the notion of user ratings, or even users, come into
> play, or the strength of the association.
> If the issue is really just storing the item-item links efficiently in
> a way that isn't in memory, how about I cook up a JDBC-based
> implementation? Seem more direct.
> On Fri, Jul 10, 2009 at 11:56 PM, Ted Dunning<>  
> wrote:
>> Yes.
>> One gotcha is that you generally have to limit document size a bit  
>> to get
>> good performance.  This is not a big deal because document  
>> normalization
>> makes it hard for these documents to be retrieved in any case.   
>> Also, these
>> are typically not good second order recommendations.  First order
>> recommendations are the top-40 kinds of things and make poor  
>> recommendations
>> for a bunch of reasons.  Second order recommendations are those  
>> that are
>> based on your history.  They make much better recommendations.
>> On Fri, Jul 10, 2009 at 3:50 PM, Jason Rutherglen <
>>> wrote:
>>> Interesting. So we're creating the item-item matrix using one of  
>>> the Mahout
>>> algorithms (like Taste?), then dumping it into Lucene.

Grant Ingersoll

Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids)  
using Solr/Lucene:

View raw message