主题：【原创】浏览器是怎么变成操作系统的 -- 美人他爹
家园 权限这东西google无所谓 它可不怕搜不到你，只有你怕被它搜不到。我发现有些网站google有快照，但是我上去它要我登录，否则不让看，估计就是有对google的bot网开一面设置。
家园 SQL!!! SQL??? sql确实让人又爱又狠
爱的是用sql 可以不动脑子 select * from XXX where XXX=XXX 这样很爽，至于底层，没必要考虑
恨的是用sql 有时候想动脑子也不行，程序员写出一些触发全表扫描或者引发死锁的sql语句简直就该杀，可这不是sql语法的问题，是dbms实现的问题，所以dba边骂娘边调优，数据库的调优有的时候需要走一些反范式的偏门，比如数据冗余，这个时候，sql怎么写，怎么维护数据完整一致，又轮到程序员骂娘。。。极端情况下，就子子孙孙骂娘无穷尽了。。。
所以才有orm框架百花齐放，目的都是尽可能让程序员能够忘掉sql，让orm全权解决sql语句的优化和数据cache，让dba踏踏实实玩儿他的dbms，这样就和谐了。
可是orm框架不和谐阿，百花齐放的结果就是无所适从，而且框架的设计也是良莠不齐，甚至有的时候比sql还复杂。。。
家园 SQL确实跟传统的编程语言不同 易懂难精。惭愧的说，我也是最近几年才真正弄通。以前自以为精通，直到某个项目之后，才明白自己的浅薄。
稍微点评一下：
这种语言首先操作的，都是数据集合不全对，在Stored Procedure里是可以一行一行来操作的，但不到万不得已，不鼓励。
这个语言，根本不关心底层的实现这个我认为是时代的进步，就像您用一把螺丝批一样，不一定要明白这把螺丝批是怎么制造的吧？
第三，这个语言的操作对象的类型是什么？没有定义，只是一个简单的table。只要这个table里面有相应的column，就可以操作。至于是不是多一column少俩column，SQL大多数时候都不在乎。这个不明白会有什么问题？
最让人不满意的是：这个语言大多数时候是不需要循环的这个估计是效率问题，举例说，您可以一次用一个Update来更新某个Table，也可以用Cursor逐个纪录来更改，一般而言，Update的效率会高很多，但是，如果更改的条件复杂的话，Update的语法比用Cursor的会笨拙很多，传统的程序员会很讨厌。
呵呵，一家之见而已，老叫化的打狗棒请放轻点！
家园 其实这些特性是数据处理中非常需要的 虽然我基本上只使用C/C++，对其它语言总是嗤之以鼻，但不得不说这些特性是C/C++以及其它程序语言在数据处理时极度缺乏的手段。我现在的工作，就是所谓的“海量数据分析”，对这些特性的需求非常强烈。然而，由于我们倾向于“分析”这一块，所以SQL本身的运算能力和效率有不能达到要求，所以还得用C/C++为主。所以，非常头痛的就是这些集合的操作了。传统的所谓容器是无法满足我们的要求的，除了数据类型的原因，更重要的是量的问题：我们的数据不大可能小于内存的容量，那些容器就都成了摆设。而和SQL接口，又由于二者的本质区别导致非常别扭，且影响效率。所以我们正在开发一个介于二者之间的东西：既具有SQL的无类型集合操作的特性，又可以方便地以数组方式操作。另外我们还需要这个玩意可以分布式存储和计算，以利用现在的廉价集群。
家园 Hadoop 听起来有点象， 而且好象也有了SQL接口。
家园 BerkeleyDB 然后分布式的就是big table
SQL只是适合部分情况。通用数据库不可能有效的处理所有case
家园 bigtable也和我们的需求有一定差异 BigTable是针对大约10年前的硬件条件设计的，我们希望我们的系统可以在10年以后的硬件条件下有较好的性能。所以，考虑10年后，摩尔定律应当在这10年对单机的计算能力仍然有效的话，则单机可有接近处理Internet规模数据的能力，但可靠性下降不少。在这种情况下，我们的设计和BigTable还是有不少差异的。
家园 能否多说一些啊？ - 复 能否多说一些啊？
家园 我们的设计兼顾计算 BigTable主要的考虑还是存储，我们希望兼顾计算，主要是方便我们调度和处理计算任务。因为在少数节点的集群上，可以把计算任务直接分配给数据存储的节点，这样就可以极大提高数据读写速度、降低网络通信量。所以我们使用分布式队列的方式组织数据，类似Amazon的SQS。这样的接口存储管理上可能更麻烦一些，但计算调度要方便一些。