作者tao2tw (smile_ting)
看板PHP
标题Re: [请益]如何设计 facebook , g+ 按赞或者+1的功能
时间Sun Mar 24 23:08:23 2013
1F:→ MOONRAKER:这样只在一个方向勉强算有效率 反过来就超级没效率 03/24 16:00
2F:→ MOONRAKER:你想一下(1)我现在又按一次赞,怎麽避免我重覆。 03/24 16:01
3F:→ MOONRAKER:(2)我现在要收回赞,怎麽把我收回。 03/24 16:01
4F:→ MOONRAKER:(3)我现在想知道我按过哪些赞(FB界面没提供,但是API有)03/24 16:02
5F:→ MOONRAKER:要怎麽办。你想一下在你设计中怎麽快速处理这三个功能。03/24 16:02
回覆 Moo大的建议,
这边我自己思考了一下。
我会考虑把 like 独立做成一个table
栏位可能就是.
post_id user_id
就这样, post_id 表示 此like 跟随哪一篇post , user_id 则是表明是谁按的赞
如此一来。
如果我需要知道 某篇post 有谁按过赞 就去搜寻 like TABLE , where post_id = XXX
同样的我也可以在 like Table , where user_id = me
去找寻我like过哪些post
如果要收回like , 只要delete 即可。
只是这样一想,觉得fb是在是太威猛了。
如果每次都要读写回database 感觉会很消耗系统资源。
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 119.77.136.156
6F:→ MOONRAKER:MOONRAKER不是Moo 我拒绝这个简写 X( 03/24 23:30
7F:→ MOONRAKER:去年我接触一个站改版 他也有这种"A,B,C"式的资料栏位 03/24 23:31
8F:→ MOONRAKER:虽然那只是分类 例如一张相片同时属於人物,旅行,心情类 03/24 23:32
9F:→ MOONRAKER:不会像「赞」那麽频繁读写 仍然使我们干得要死 XD 03/24 23:32
10F:→ MOONRAKER:可那个站以前也还能够营运那麽久还不出事情 可能的解释 03/24 23:33
11F:→ MOONRAKER:就是这样设计对资料库的压力究竟如何 也不是那麽简单 03/24 23:34
12F:推 gpmm:推一个自己想,压力这件事可以用 memcache 来解啊 XD 03/24 23:55
13F:推 chenlarry:FB的效能是用钱砸出来的,他们买很多记忆体,但到底有多 03/25 00:31
14F:→ chenlarry:少我不记得了,但我印象中很大,非常大... 03/25 00:31
15F:→ chenlarry:刚刚查了一下资料,FB有800台伺服器,记忆体有28TB.... 03/25 00:37
16F:推 sin282:AKER大 正名 03/25 14:08
17F:→ alpe:FB印象中用了不少NoSQL的方案. 03/26 00:18