主题：【原创】对SNS架构的非典型性批评 -- 邓侃

人类几千年来，对性和情感有着经久不衰的兴趣。互联网用户搜索sex和love的频率统计，印证了这个印象。如图一所示，比较sex和love两个热点词的搜索频率，特点是用户对这两个词的兴趣，不仅持久，而且稳定。

所以，很多社交网，不约而同地以美女为卖点，炒作人气。但是，根据下图的启示，拿美女做药引子，虽然的确可以积累一定的人气，而且能够持续地维持人气指数，但是不能指望这种做法能够把社交网的规模，拉动到更高水平。

图一还包含另外几个有趣的信息。

1. Sex比love更受人欢迎，估计口味重的东西更有卖点。

2. Google和sex的吸引力不相上下。

3. Facebook的增长势头不可小视，最近，facebook的吸引力已经超过了sex。

4. Youtube的增长势头最为客观，远远超过了人类对性和情感的需求。

Facebook 的吸引力超过了sex和google，所以IT业界普遍认为，以facebook为代表的SNS（Social Network System），比Google更有潜力。Facebook什么时候进中国？其实它来不来无所谓，因为国内已经出现了多个facebook的克隆，如校园网，豆瓣网，海内网，还有最近进入高热的5G，五季网。

怀着对SNS的好奇，最近我阅读了一些SNS的架构设计。拿5G做例子，它的后台支撑，用的是开源的UCenter Home（UCH）平台。与Facebook的架构，以及很多其它SNS架构一样，UCH的架构整体设计遵从了3-tier的思路。

传统的3-tier架构，前端为presentation tier，负责网页的组织和用户的交互。中间是logic tier，负责分头处理各种业务逻辑。后段是数据库，尤其是关系式RDBMS，以硬盘为终点，存储数据。如图二所示。

拿这样的架构去支持SNS，个人感觉有两方面的疑问。1. RDBMS是否有必要。 2. 内存使用的重复。

用RDBMS来管理SNS内容是否有必要？分几个子问题。

1. SQL：SQL有没有必要？绕过它如何？

SQL用起来简单，但是任何便捷都是有代价的。对于SNS来讲，这个代价就是吞吐量。

SQL的执行分几个步骤，解析SQL语句，生成执行计划，提取数据，数据的合并排序等等后处理。

SQL发展了30多年，语法变得很复杂。无论用户如何组织SQL语句，SQL解析器都必须能够读得懂用户想干什么，而且生成相应的，最好是效率不太差的执行计划。这使得SQL parser变得庞大，庞大就意味着行动迟缓。

假如我们不用SQL如何？在业务逻辑中直接把执行计划写清楚，这样就可以省掉两步工作，解析SQL语句，生成执行计划。从而，提高整个系统的效率，增加吞吐量。

2. RDB，关系式数据模型对于SNS内容是否合适？文件系统是否更合适？

若干行若干列的表结构对于处理银行业务是合适的，因为银行业务数据大都是结构化（structured）的数据。但是SNS的内容不是，有的时候帖子很短，“顶”，一个字的帖子不少。有时候字数很多，还有表格，图片，甚至视频等等。所以SNS的内容是非常典型的非结构化（non-structured ）数据。

如何存储这样非结构化的数据？BLOB或者CLOB。

LOB实际上已经游离于RDB的表结构，作为文件附件存在于数据库中。

为什么不直接用文件系统，而是削足适履一般地，强行把SNS内容塞进RDB的外壳，却无视数据库内部其实用的仍然是文件系统呢？

3. DBMS，以B-tree为核心的DBMS，对于检索更改SNS内容是否合适？Inverted index是否更合适？

对于检索关键词而言，B-tree不是很好的数据结构。但是它的好处是更新快，包括增加，删除和修改。

问题是，SNS不是银行，银行在一秒中内可能要支持几百万个交易，但是每个交易或许只涉及个别字节，如金额数等。但是SNS的交易，通常是以整篇帖子为基本单位，而不是以某个表格中的某行某列那种数据碎片为基本单位。即便用户很多的SNS，也不会出现银行那样的高频率交易。

Inverted index是否更适合SNS？虽然不能支持每秒几百万次的交易，但是搞一个大桶，若干小桶。对于更新来说，足够应付。

Inverted index最大的好处是利于检索非结构化文本数据。光这一条，和B-tree比较起来，B-tree就处下风。

4. 为什么要用DB？彻底的怀疑论。

银行为什么要用数据库？几个原因，1. 对于每一笔交易，要不不做，要做就做完（atomicity），2. 一致性（consistency），说好了用户婚姻状态一栏，要么填“单身”，要么填“非单身”。如果有用户填“我不告诉你”，数据库就应该提示错误信息。3. 隔离（Isolation），同时进行的两个交易，不应该相互干扰。4. 持久（Durability），用户几十年前存的钱，不能平白无故地就消失了。这就是所谓交易的（ACID）特性。

银行的交易通常涉及到钱这样critical的数据。SNS的内容可没有这么critical，丢了一个帖子就丢了吧，别经常出错就行，但是不像银行那样零容忍度。所以SNS没有必要花过份的代价去保障ACID。没有必要保障ACID，还要数据库做什么？

是不是把MySQL或者Oracle DB换成Google的Bigtable就满意了呢？好一些，但是还不是完全满意。

以后找时间接着批评内存使用的重复，讨论Google bigtable。同时回答另一个问题，Google云计算平台是否适合SNS。

SNS出现确实

不知道怎么描述

但是你的表格看着很有意思，FACEBOOK的数据

早些年有所谓ＸＭＬ　ｄａｔａｂａｓｅ，一个同事跟我吹这个是业界未来，会取代Ｒｅｌａｔｉｏｎａｌ　Ｄａｔａｂａｓｅ。但我实在想不通，数据量大的时候，如何能够提高表现？　于是反驳不可能。现在看，这场争论应该是我赢了。

我能想得到的几个原因

其一，是ＳＱＬ接近标准化，不同品牌的数据库之间的ＳＱＬ很小，易上手，程序员众多

其二，经过多年的优化，数据存贮速度已经不是很大问题了

其三，对大量数据的统计处理实在方便。

存在就是合理，没有其他数据存取技术，能够同时满足以下条件：

１，更快的表现

２，更容易上手，

３，更容易统计

如果有的话，ＳＱＬ就会退出舞台了。

回到SNS上面来，应该说，有的内容还是Ｓｔｒｕｃｔｕｒｅｄ，例如个人信息等等，这部分用Ｒｅｌａｔｉｏｎａｌ　ＤＢ是没有问题的。

另外一部分，例如上载图片，完全不必存放在ＤＢ里，ＤＢ里可以只存放图片的路径。

总而言之，Ｒｅｌａｔｉｏｎａｌ　ＤＢ不过是创建SNS的一个工具而已，不必刻意绕过它吧？

之前被人拉着注册了开心网，用的自己的真名，后来发现之前同事，学校同学很多都在里面，如果真要都加好友，真是一个庞大的社交群，还有其他公司客户和同行之类，但开心网现在组件之类都还比较烂，我基本是属于纯去玩的，如果河友有兴趣也可以加我，我的email是[email protected]。比较正经的我觉得行人脉网，https://www.xing.com/还不错。

五度能不能给我发个邀请？email: [email protected]

先谢了。

恭喜：你意外获得【通宝】一枚

鲜花已经成功送出。

此次送花为【有效送花赞扬，涨乐善、声望】

完全同意。

社交网的主要内容是帖子和照片，或许还有MP3和视频。这些东西，用RDBMS是不合适的。

要说分歧，我和大厨的不同之处在于如何看待SQL。大厨的论据都是对的，SQL易学，功能多。

问题在于tradeoff，开发难度vs用户体验，偏重哪一个？

如果让我选，我会让用户享受最快的服务，而把开发的难度留给工程师。

我是极端分子，呵呵。

我会先看看有多少钱可以烧，再下决定。。。。。

我是现实主义者！

好像这样就可以，所之兄点这个试试

http://www.kaixin001.com/reg/?uid=499241&usercode=d72f16109c9aeeee5788b40fa6d5616b_499241__%E6%99%AE%E9%80%9A%E6%9C%8B%E5%8F%8B

[email protected]

邀请

多谢五度，我加入了开心网。

开心网没有公共区域。你先要发展一堆朋友，否则好像没法玩。

为什么开心网比豆瓣网更有人气？

这个其实有点搞笑，都是朋友拉朋友，所以新手就跟着老手完了，像徒弟带师傅。我朋友列表多是现实生活认识或者网上有过交流的网友。开心网我感觉定义上就是大家来玩，像投票之类都是没事按两下，包括停车组件等都是简单上手，给朋友间一个互动。个人感觉豆瓣其实比较有料，但估计因为开心网简单娱乐，所以反而比较受人欢迎。