- 程序有所改变。发帖如还有问题请报告
- 【征集】西西河的经济学，及清流措施，需要主动参与者，『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【原创】对SNS架构的非典型性批评 -- 邓侃
家园 【原创】对SNS架构的非典型性批评 人类几千年来，对性和情感有着经久不衰的兴趣。互联网用户搜索sex和love的频率统计，印证了这个印象。如图一所示，比较sex和love两个热点词的搜索频率，特点是用户对这两个词的兴趣，不仅持久，而且稳定。
所以，很多社交网，不约而同地以美女为卖点，炒作人气。但是，根据下图的启示，拿美女做药引子，虽然的确可以积累一定的人气，而且能够持续地维持人气指数，但是不能指望这种做法能够把社交网的规模，拉动到更高水平。
图一还包含另外几个有趣的信息。
1. Sex比love更受人欢迎，估计口味重的东西更有卖点。
2. Google和sex的吸引力不相上下。
3. Facebook的增长势头不可小视，最近，facebook的吸引力已经超过了sex。
4. Youtube的增长势头最为客观，远远超过了人类对性和情感的需求。
Figure 1. Comparison of the trends of sex, love, facebook, youtube and google.(Courtesy of Google trends)
外链图片需谨慎，可能会被源头改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，以硬盘为终点，存储数据。如图二所示。
Figure 2. 3-tier infrastructure.（Courtesy of Wikipedia）
外链图片需谨慎，可能会被源头改拿这样的架构去支持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的本质是什么，都有哪些表现形式，国内外对SNS的理 解有什么区别。这方面邓大能否开篇文章说说呢？
我前段时间有个想法，将SNS和MAP结合起来，形成一个Local SNS，不知会怎样。
我先抛砖，期待大家的璞玉！
家园 能教我怎么在facebook中编组建么？ 家园 Ucenter是Discuz开发的那个么？ 传统的LAMP，PHP+DB的架构，说是三层，逻辑三层还勉强，物理三层就说不通了。其实，99%的应用是全装在一台机器上的。
如果对SNS的architecture感兴趣，这里有个在业内很出名的经典blog ，介绍了不少有名的大型SNS的architecture，如youtube，amazon，flickr，google，facebook等。
家园 架构设计blog 这个blog很有意思，值得好好读读。
多谢。
UCenter的确是Discuz开发的。功能还是不错的，用户量少的时候，用户体验相当好。
家园 没那么复杂 这些大网站一般只把用户信息和管理信息放在DATABASE。其它的非关键内容（text,photo,a/v)都放在文件里。DATABASE是最难SCALE UP的，什么都放里面非崩溃了不可。
家园 谈两个数据库问题 数据库管理之一是提高硬盘读出速度。如一个条目可能会有更改，（如客户帐户会随每一个交易而更改），如果是文件管理的话，没一次更改都可能使得硬盘存储碎片化，最终会导致检索时硬盘读取成为瓶颈，大大降低应用的速度。数据库管理可以调节每一个条目的储存空间，防止条目的更改导致硬盘存储的碎片化。
一般来说，设计数据库的时候要根据数据库应用逻辑来选择合适的数据结构。有些数据适合插入更改快的算法，有些数据结构适合检索读取快的算法。这可以对应应用时修改插入多还是检索读取多来选择。但是，对于同时需要大量频繁插入和检索的应用，往往难以找到合适的数据结构－算法方案。为了解决这个难题，一种方法就是用插入快的数据结果来建立不断更新的数据库，然后把昨天的数据库改成检索快的数据结构用于检索老数据库。Cognos Impromptu 就是用的这种方法，如管理层需要的数据分析可以根据昨天以前的数据来检索而不必看今天的动态数据，就可以每天晚上重组一个检索快而无需插入更新的数据库，以提高读出速度。
真正的问题还是如何把信息组织成知识。
- 复 谈两个数据库问题
家园 兄台高论,受教了 “真正的问题还是如何把信息组织成知识。”
兄台高论,受教了
- 复 谈两个数据库问题
家园 西西河里DBA如过江之卿啊，呵呵 说到Data Warehouse，BI， ETL，这里有个Database 的blog不错，热点话题很多，值得一读：
如ETL： To ETL or federate ... that is the question
BI与Cloud：There's a bright cloud on the horizon ... and it will transform the economics of BI
DBA眼里看MapReduce：MapReduce: A major step backward
家园 MapReduce的评论，倒退 虽然我很喜欢读这篇文章，完全不同意这个DBA的论点。
计划在今后谈到MapReduce的时候，把我的意见写下来。
家园 这俩位爷可不是普通DBA 自Jim Gray失踪以后,这俩就是数据库领域的大当家和二当家. 否则也不敢说样的话.
他的观点其实是: Mapreduce是个好东西,但不是scalablity的万灵丹.至少在数据库领域,咱哥俩就不承认.
家园 得罪了牛人 多谢提醒。
我对牛人有崇拜情结。既然是两位掌门人，那么他们的文章还得二读三读。否则不敢冒然作乱。
家园 那就等你的好贴了 昨天看到一则消息，有个startup自己利用mapreduce原理开发了个支持SQL的datawarehouse，估计这次可以赢得许多DBA们的好感了，不过与你前面所提的SQL overhead问题似乎是有百害而无一利，呵呵。
文中也提到Apache opensource主持的Hadoop与微软的科研院项目Dryad， 其中Hadoop更是被yahoo与NY Times采用多年了:
Aster and Greenplum aren't the only ones taking advantage of MapReduce. Apache has also developed an open source version of MapReduce known as Hadoop.Yahoo (NSDQ: YHOO) uses Hadoop for Web search and advertising, and The New York Times has used Hadoop in combination with Amazon (NSDQ: AMZN) Web services to transform millions of old articles that were each in several disparate scanned TIFF images into PDF format. Microsoft (NSDQ: MSFT) Research has developed a similar parallel computing framework known as Dryad.
- 复 谈两个数据库问题
家园 说得好极了 我得赶紧写了。
诸位的问题和评论写得太好了，加紧写，把这些有意义的讨论深入下去。
家园 数据库应该是必需的 对数据挖掘或者数据关联非常重要。类似的网站，最重要的功能就是“网”住人与人之间的关系，一般的文件系统可以做到数据的保存，但是无法做到数据之间的关联，也就无法实现参与者之间的关联