[ 
https://issues.apache.org/jira/browse/SPARK-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14060474#comment-14060474
 ] 

Sean Owen commented on SPARK-2465:
----------------------------------

Yeah, more data is a cost for sure. I had though it was mostly an in-memory 
cost since these data structures get cached in memory, and/or you are 
processing parsed blocks rather than individual Rating objects. It might be 
~25% more raw data?

This kind of densification is an error though, right? I treat two users as if 
they're the same when they are not. I think 0.1% collision is quite high -- 
every thousandth user or so is getting recommendations for some other person. 
You also end up reporting that certain users and items have no presence in the 
model.

If my estimate is right you end up with that kind of collision rate with a ~2 
million users or products and a 32-bit hash. It's 'safe' up to a hundred 
thousand or so (0 collisions is more probably than >0)

Did you mean you've benchmarked this to see the blow-up or can do so? I agree 
that it really depends on the cost. I had thought it was probably "not bad" 
compared to being able to hash more reliably.

> Use long as user / item ID for ALS
> ----------------------------------
>
>                 Key: SPARK-2465
>                 URL: https://issues.apache.org/jira/browse/SPARK-2465
>             Project: Spark
>          Issue Type: Improvement
>          Components: MLlib
>    Affects Versions: 1.0.1
>            Reporter: Sean Owen
>            Priority: Minor
>         Attachments: Screen Shot 2014-07-13 at 8.49.40 PM.png
>
>
> I'd like to float this for consideration: use longs instead of ints for user 
> and product IDs in the ALS implementation.
> The main reason for is that identifiers are not generally numeric at all, and 
> will be hashed to an integer. (This is a separate issue.) Hashing to 32 bits 
> means collisions are likely after hundreds of thousands of users and items, 
> which is not unrealistic. Hashing to 64 bits pushes this back to billions.
> It would also mean numeric IDs that happen to be larger than the largest int 
> can be used directly as identifiers.
> On the downside of course: 8 bytes instead of 4 bytes of memory used per 
> Rating.
> Thoughts? I will post a PR so as to show what the change would be.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to