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

简单就是美。

的需求和使用关系数据库不矛盾。

试图借鉴它的某些思想捣饬大量数据和网络，debug很脑袋痛。

对数据挖掘或者数据关联非常重要。类似的网站，最重要的功能就是“网”住人与人之间的关系，一般的文件系统可以做到数据的保存，但是无法做到数据之间的关联，也就无法实现参与者之间的关联

数据库管理之一是提高硬盘读出速度。如一个条目可能会有更改，（如客户帐户会随每一个交易而更改），如果是文件管理的话，没一次更改都可能使得硬盘存储碎片化，最终会导致检索时硬盘读取成为瓶颈，大大降低应用的速度。数据库管理可以调节每一个条目的储存空间，防止条目的更改导致硬盘存储的碎片化。

一般来说，设计数据库的时候要根据数据库应用逻辑来选择合适的数据结构。有些数据适合插入更改快的算法，有些数据结构适合检索读取快的算法。这可以对应应用时修改插入多还是检索读取多来选择。但是，对于同时需要大量频繁插入和检索的应用，往往难以找到合适的数据结构－算法方案。为了解决这个难题，一种方法就是用插入快的数据结果来建立不断更新的数据库，然后把昨天的数据库改成检索快的数据结构用于检索老数据库。Cognos Impromptu 就是用的这种方法，如管理层需要的数据分析可以根据昨天以前的数据来检索而不必看今天的动态数据，就可以每天晚上重组一个检索快而无需插入更新的数据库，以提高读出速度。

真正的问题还是如何把信息组织成知识。

这些大网站一般只把用户信息和管理信息放在DATABASE。其它的非关键内容（text,photo,a/v)都放在文件里。DATABASE是最难SCALE UP的，什么都放里面非崩溃了不可。

这个问题的实质是“结构化数据”与“非结构化数据”之争，目前还是打架阶段。

政治上，内容管理供应商想借此打败数据库供应商，数据库供应商想借些把内容管理收进来。微软也想进来，不是有个用SQL Server做文件系统的项目吗。

实质上，想想，文件系统不是数据库吗？数据库不能做为文件系统吗？

工程上，最终，只要能满足业务需求，就是好的解决方案！

比如象 flickr 这样的图象网站，存储后台会用文件方式，还是会用数据库的方式呢？

应该是专用的图片服务器，用文件的方式存图片。这样，这台服务器只为大规模图片文件吞吐进行优化。

图片的链接及相关元数据信息，存入另外的RDBMS服务器中，为查询而优化。

两个互不干扰，应该是目前条件下最优的解决方案了。

当然，这样做之后，ACID会出问题。不过图片发送这种应用没银行要求那么高，好对付:)

或者干脆是重新设计的。

用RDBMS来存储图片，表面上看是存在数据库里，其实数据库是把图片当着BLOB存的，BLOB实际上就是文件。

所以，与其绕一个弯子把图片存在数据库里，不如直接存成文件得了。

当然，像用户信息等等之类，用RDBMS存，很方便，也很安全。

说得好。

看来我的系列得快点写了。等一等，很快就会谈到小女生提及的问题，改良文件系统。

我得赶紧写了。

诸位的问题和评论写得太好了，加紧写，把这些有意义的讨论深入下去。