主题：【原创】对SNS架构的非典型性批评 -- 邓侃
家园 我的极端想法 SQL是否有必要，我的极端想法是这样的。
如果用户需要在command line操作数据，那么有SQL会很方便。
如果用户永远是在程序中与数据库打交道，通过JDBC加上SQL，就是累赘。
SQL的好处是方便，坏处是增加额外环节，譬如编译SQL，生成执行计划，以及合并数据等等。
另外，如果SQL的语句写得稍微复杂一点，效率优化也是大麻烦。需要通过专门的工具看编译器生成的执行计划是什么，如何改写SQL语句，使执行计划更有效率。
感觉就像是为了提高Java的执行效率，要求Java程序员透彻了解Java bytecode一样。或者要求C++程序员，明白对应的汇编语言一样，这个要求有点不合情理。
所以，我的极端想法是，与其惹SQL那份麻烦，不仅程序运行效率低，而且对程序员要求高，能不用就尽量不去惹事，和自己过不去。
当然，我知道这个想法比较另类，绝大多数人不会同意。呵呵
- 复 我的极端想法
家园 执行计划之类恐怕不是瓶颈吧 对于大部分商业DBMS来说，执行计划都是有缓存的。楼主贴貌似过于强调当前DBMS的执行效率问题，但是方向不怎么对头。从我个人的经验来看，真正影响效率的还是系统内存管理（Cache管理），磁盘操作。真想做一个大规模的数据处理系统，不管是DBMS还是别的什么这都是绕不过的地方。
另外，关系数据库是一种设计模式，在做数据架构设计的时候，决定了设计人员的数据组织思路。如果说关系数据库不适合SNS系统的话，我认为更有说服力的因素的设计思路的限制，而不是界面层到数据层的执行效率问题。因为这个问题是跑不掉的，除非新的系统只有一个层次。
- 复 我的极端想法
家园 一点不极端 早年MySQL之所以流行起来，一个主要因素就是速度快，因为它老的版本没有transaction的机制，当然速度快了。 另一个有名的快速数据库是BerkeleyDB，也是这种丢三拉四的，但是轻装上阵，现在好多软件自带SQLLite，有点重走MySQL老路的架式，但这样的需求看来总是存在的。
前两天看到某异人的blog，正在准备做个project，准备把DB里面的stored proc什么的都去掉，做个轻便DB云云，而且不是闲着玩的，似乎是个某公司立了项的，但一下子找不到那个blog，当时看了也就一笑了之，心想等弄出点名堂来自然说的人多了，再研究不迟。 是不是你也是受了什么启发，按说老中里喜欢动歪脑筋的人不多，即然你吞吞吐吐的，那么葫芦里面装的什么药就快倒出来吧，让大家帮你参谋参谋？
- 复 一点不极端
家园 冤枉我了 按说老中里喜欢动歪脑筋的人不多，即然你吞吞吐吐的，那么葫芦里面装的什么药就快倒出来吧，让大家帮你参谋参谋？冤死我了，在“闲聊Google集群”系列的第一篇，一开场我就交代了动机。
大家能到我这里来工作，是大家的缘分。5年后，10年后，大家会在哪里，很难说，或许各奔东西了吧。我要问的是，公司能够给大家每一个人做一点什么？
所以就读论文了，刺激大家对专业的热爱，最好，几年后大家都有能力做架构师。
至于SQL，我质疑它很久了。但是目前还没有打算动手挑战。BerkeleyDB我很认真地用过，后来放弃了。原因是存储数据的规模大了以后，速度就慢下来了。我猜测，问题出在data的serialization上。有待证实。
吞吞吐吐有点冤枉，喜欢动歪脑筋导师很贴切。极端的思想有个好处，就是能够刺激思想的深度。但是不必急于把极端思想付诸实施，反复权衡，拿捏准了再下手不迟。
家园 “结构化数据”与“非结构化数据”之争 这个问题的实质是“结构化数据”与“非结构化数据”之争，目前还是打架阶段。
政治上，内容管理供应商想借此打败数据库供应商，数据库供应商想借些把内容管理收进来。微软也想进来，不是有个用SQL Server做文件系统的项目吗。
实质上，想想，文件系统不是数据库吗？数据库不能做为文件系统吗？
工程上，最终，只要能满足业务需求，就是好的解决方案！
家园 看了你的回复，突然想起一个问题来 比如象 flickr 这样的图象网站，存储后台会用文件方式，还是会用数据库的方式呢？
家园 抖胆猜下 应该是专用的图片服务器，用文件的方式存图片。这样，这台服务器只为大规模图片文件吞吐进行优化。
图片的链接及相关元数据信息，存入另外的RDBMS服务器中，为查询而优化。
两个互不干扰，应该是目前条件下最优的解决方案了。
当然，这样做之后，ACID会出问题。不过图片发送这种应用没银行要求那么高，好对付:)
家园 del