主题：【原创】对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。