二度人脉架构设计大讨论

漂在北京 发布于 2012/06/21 17:21
阅读 995
收藏 2

现在SNS网站中这种人脉都有这种设计实现,有没有高人做过二度人脉这种设计的?

一个用户假设按照6度理论有120个好友(包括同事、同学、亲人等),那么这个用户的二度人脉则为120 * 120;

关于数据的存储:这个用关系型数据库来设计的话似乎比较复杂, 在网上搜索了下看有人用百度 TokyoTyrant来实现的。

关于数据的来源:我觉得也可能是有一个计划任务在定时做统计;

以下是问题补充:

@recrec:推荐二度人脉的好友应该如何实现呢? (2012/06/25 10:40)
加载中
0
中山野鬼
中山野鬼
这个和数据库毛关系没有。是个图的问题。再抽象说,是距离为2的网络图的问题。而且不是简单的 n^2的事情。
0
漂在北京
漂在北京

引用来自“中山野鬼”的答案

这个和数据库毛关系没有。是个图的问题。再抽象说,是距离为2的网络图的问题。而且不是简单的 n^2的事情。
这个数据是怎么计算出来的?  有什么算法么?不知道中山有没有类似工作经历,还请详细介绍下啊
0
中山野鬼
中山野鬼

引用来自“王XX”的答案

引用来自“中山野鬼”的答案

这个和数据库毛关系没有。是个图的问题。再抽象说,是距离为2的网络图的问题。而且不是简单的 n^2的事情。
这个数据是怎么计算出来的?  有什么算法么?不知道中山有没有类似工作经历,还请详细介绍下啊

图的东西,倒正在做。人脉的东西没做过。这个东西小了无所谓,大了。一堆问题就出来了。包括分布存储,分布计算等等。

原理上的模型就很关键,后面的工程上的更繁琐。简单说,你一个服务器上能容纳10万个人,他们相互之间有朋友关系。你的意思是要分析,一个人A的朋友B的朋友C,那么A,C之间有什么关系是你要获取的。那么如果第10万零1个人,需要放到另一个服务器上,恰巧是B,哈,难道你两个服务器来回折腾?

一般做法是图分割,但是有冗余。以保证任意一个人的距离为2的朋友都能在一个服务器上有数据。这个时候有会出现多个服务的数据同步问题。

其实还有其他问题。例如新增了一个人,由于他的出现,导致图的结构产生了变化,你又需要调整图的结构。根据一个固定结构,遍历或查询是可以把计算复杂度控制住的。但是结构的变化,可能导致你的整体图涉及结构方面的整体刷新。

或许有人说图的节点用动态链表方式折腾。哈。64位机器,一个地址就64位,偏移量方式,你可以24位或者32位折腾,由此可能导致CACHE内两种不同的方式,能容纳结点的数量有倍数以上的差异。而且备份到外部存储介质后再读取上来,你一样需要逻辑地址的重新刷新。

一堆事情。其实还有很多其他细节要处理。你现在让我列问题,我能列,你让我出解决方案。我更本出不了。为什么?因为我根本不知道业务背景是什么,硬件设备资源怎么样,未来系统扩建有什么规划,我什么都不知道,也自然不知道评价标准,没有评价标准,空谈方案,纯粹狗屁。哈。

 

0
deleted
deleted

TokyoTyrant不是百度的,是fallabs的, 而且很久不维护了, 改做kyototycoon了....据说tt数据上千万后容易出问题

二度人脉我见过几个用neo4j做的

0
中山野鬼
中山野鬼

引用来自“勇者天空”的答案

TokyoTyrant不是百度的,是fallabs的, 而且很久不维护了, 改做kyototycoon了....据说tt数据上千万后容易出问题

二度人脉我见过几个用neo4j做的

上千万容易出问题很正常。搞架构的不懂业务。搞业务的,没有长远规划,搞规划的,压根不碰项目,于是乎就跌跌碰碰。这样的团队通常认为创意更值钱,平台无所谓。哈。
返回顶部
顶部