LIKE CODING: MJ [10] CanView Design
Design a system to meet the following requirements:
boolean CanView(Viewer, Object, Owner);
Return true if viewer can read object of owner; otherwise return false.
object has one property which can be public or friends. If it is public, viewer can read object; if it is friends, only friend of owner can read object.
http://stackoverflow.com/questions/8663072/database-design-for-social-network-friends-list-friends-circle-post-sharing
http://www.mitbbs.com/article_t/JobHunting/33022171.html
The problem can be reduced to an isFriend design.
You have 2 users, check if they are friends. There's a classic RDBMS design
and there's a NoSQL design. it's not hard either way.
我觉得这个设计包含两个部分，
1. Object Meta data的storage
2. Friend relationship的管理.
对于1，可以用distributed hash map + memcached解决
对于2，可以参考facebook的TAO设计。就是说维护A-FRIEND-B的GRAPH。对于两个朋友
，使用两个有向边维护。为什么用graph，而不是一般的map设计（比如，A的朋友表示
为A->[B, C, D, ....]）？我觉得主要是scale问题。对于facebook这样这么大的用户
量，用户之间联系这么复杂的，使用map引起的写操作和写锁会非常难处理。对于这个
friend的有向图，主要是处理A-FRIEND-B这样的三元组的读写。那么可以使用
distributed hash map+index。并且用cache加速读操作。可以通过直接写cache，
batch写disk得方法解决写速度问题。
看看graph db，比如neo4j之类的设计思想
大概就有谱了
Read full article from LIKE CODING: MJ [10] CanView Design
Design a system to meet the following requirements:
boolean CanView(Viewer, Object, Owner);
Return true if viewer can read object of owner; otherwise return false.
object has one property which can be public or friends. If it is public, viewer can read object; if it is friends, only friend of owner can read object.
http://stackoverflow.com/questions/8663072/database-design-for-social-network-friends-list-friends-circle-post-sharing
http://www.mitbbs.com/article_t/JobHunting/33022171.html
The problem can be reduced to an isFriend design.
You have 2 users, check if they are friends. There's a classic RDBMS design
and there's a NoSQL design. it's not hard either way.
我觉得这个设计包含两个部分，
1. Object Meta data的storage
2. Friend relationship的管理.
对于1，可以用distributed hash map + memcached解决
对于2，可以参考facebook的TAO设计。就是说维护A-FRIEND-B的GRAPH。对于两个朋友
，使用两个有向边维护。为什么用graph，而不是一般的map设计（比如，A的朋友表示
为A->[B, C, D, ....]）？我觉得主要是scale问题。对于facebook这样这么大的用户
量，用户之间联系这么复杂的，使用map引起的写操作和写锁会非常难处理。对于这个
friend的有向图，主要是处理A-FRIEND-B这样的三元组的读写。那么可以使用
distributed hash map+index。并且用cache加速读操作。可以通过直接写cache，
batch写disk得方法解决写速度问题。
看看graph db，比如neo4j之类的设计思想
大概就有谱了
Read full article from LIKE CODING: MJ [10] CanView Design
