对Google算法优越性的一点小体会

benjiam

原帖由 zszyj 于 2008-6-25 11:31 发表
[quote]原帖由 benjiam 于 2008-6-25 11:04 发表



"gmail 需要多少台 web   服务器， 他们需要和数据库建立连接？ 1格数据库。所有用到这个业务的服务 ...

"gmail 需要多少台 web   服务器， 他们需要和数据库建立连接？ 1格数据库。所有用到这个业务的服务都需要连接这个数据库，现在是gamil
其他的呢？b c d e f . 全都连上这个库，是常 ... "

还是显示你自已的幼稚．　先去弄清楚什么是多层架构，什么是数据库连接池，　什么叫分布式数据库，　再回来讨论吧．　就你？还差得远！
说你烂是有根据的。  


第一 google 在创立初期 根本没有能力建这样的多层 连接池。

第二 多层连接池 这样的架构 根本不适合 google

第三 建系统核心架设在db 上面，靠db完成本来就是错误的。


＂插入的时候， 锁不锁表。 锁多久， 颗粒多大。 异常怎么处理？ 如何处理数据库的异常。  数据库出一点问题。 整个google 就停下来？＂
不懂什么叫行锁吧？　数据库的异常处理能力，不正是它最大的强项？　自已先了解清楚再说吧．

行锁？  虽然我db不太玩， 但是 行锁还是知道的。  考虑一下google 的用户量吧。 考虑一下 google的服务器数目吧， 考虑一下
每分钟 google 都有可能有1 台服务器当机。   

想像一下， 一个数据库 瞬间被几万格服务器 连上，然后 的 几十万格请求锁住， 然再放开。 很壮观！然后再有很多服务器当机，不断的有新服务连上数据库， 再断掉。

分布式解决。 很好， 但不是你这么解决的。  延迟， 稳定， 故障。

zszyj

原帖由 可恶的 于 2008-6-25 10:07 发表


踢球好，混挨踢也要多锻炼身体嘛
没想到数据库能够那么强大，学无止境啊。

感谢zszyj的言论，指点迷津了。

客气了，　我只是实话实说，欢迎参与客观讨论．

wwwsq

原帖由 zszyj 于 2008-6-25 11:31 发表
[quote]原帖由 benjiam 于 2008-6-25 11:04 发表



"gmail 需要多少台 web   服务器， 他们需要和数据库建立连接？ 1格数据库。所有用到这个业务的服务 ...

区区不才，需要每天处理几亿条新增消息，一年是几百亿。经常要从所有数据（几千亿条）中做特定的查询。所以根据业务需要写了一个特别的存储系统，速度比标准数据库要快几个数量级，软硬件成本降低了几个数量级。

标准数据库肯定是强大的，凝聚了无数天才的努力。但是具体到我们的特殊的业务，有特殊的需要，有时候标准数据库就不如特定的解决方案了。

你自己没做过，就不要以为别人也一定没做过。

[ 本帖最后由 wwwsq 于 2008-6-25 12:01 编辑 ]

cx6445

原帖由 wwwsq 于 2008-6-25 11:56 发表



区区不才，需要每天处理几亿条新增消息，一年是几百亿。经常要从所有数据（几千亿条）中做查询。所以根据业务需要写了一个特别的存储系统，速度比标准数据库要快几个数量级，软硬件成本降低了几个数量级。 ...

这个同意，但如果不是特别的牛，还是利用数据库比较保险。

wwwsq

原帖由 cx6445 于 2008-6-25 12:01 发表


这个同意，但如果不是特别的牛，还是利用数据库比较保险。

不需要特别牛。真的不用。那个存储系统，随便找几个合格的计算机系毕业生都可以做好。只是你想不想去做的问题。标准数据库难做，是难在要“面面俱到”。而我们恰恰不需要“面面俱到”。

你只要考虑：什么时候用什么技术。

当标准数据库合适的时候，就用标准数据库。当标准数据库不合适的，就用其他技术。这是再简单不过的道理。

不要“唯数据库论”。

[ 本帖最后由 wwwsq 于 2008-6-25 12:07 编辑 ]

zszyj

原帖由 benjiam 于 2008-6-25 11:47 发表

"gmail 需要多少台 web   服务器， 他们需要和数据库建立连接？ 1格数据库。所有用到这个业务的服务都需要连接这个数据库，现在是gamil
其他的呢？b c d e f . 全都连上这个库，是常 ... "

还是显示你自已 ...

看你技术眼界挺一般，但倒说得自已是googlec的老板似的，有机会你自已先到google了解系统架构再说吧．
顺便纠正一下你混乱的逻辑：
１．使用连接池技术，并不需要你说的几万吧服务器同时连上数据库又同时断开，你还是没弄明白什么叫数据库连接池．
２．使用连接池技术，几万台ＷＥＢ服务度在同一瞬间占用的并发连接数也就1000个之内．
３．即使是google，也没有繁忙到同一瞬间新增几万用户的可能性，能达到几百就不错了．
４．你还是没弄明白数据库锁机制，行锁是只有并发更新同一行记录时会使用，　查询是根本不会加锁的，因此更不可能出现你说的，几十万吧数据库服务器同时对数据库加锁的情况．
５．ＧＯＯＧＬＥ的服务器数目也就是数千的级别，没有你说的几十万这么可怕．可以不同的数据内容，是放在不同的数据库上的．
最后不得不说一句不客气的话，再和你纠缠下去，我都觉得有点丢人，感觉是和一个外行人在吵架一样．咱们都还是省省吧，留点时间给真正的高手说说话．

cx6445

想像一下， 一个数据库 瞬间被几万格服务器 连上，然后 的 几十万格请求锁住， 然再放开。 很壮观！然后再有很多服务器当机，不断的有新服务连上数据库， 再断掉。
－－－－－－－－－－－－－－－－－－

哪个公司的一个数据库服务能被几万个应用服务器相连？没见过这么牛B的数据库，db并发连接能上万的，能不能介绍一下。

lFANS

因为庞大的数据库里面安装一定规律处理，所以不是在1亿里面查找，可能是1万条比较，例如cndefu这个用户，会在user_c表里面查找，表示重c开头的用户名！

wwwsq

原帖由 zszyj 于 2008-6-25 12:05 发表

看你技术眼界挺一般，但倒说得自已是googlec的老板似的，有机会你自已先到google了解系统架构再说吧．
顺便纠正一下你混乱的逻辑：
１．使用连接池技术，并不需要你说的几万吧服务器同时连上数据库又同时断 ...

同学，有点常识再来参加讨论。

http://bbs.chinaunix.net/viewthread.php?tid=773865
“技嘉科技每月向Google公司供应的服务器主板数量已经达到3万块”

注意，是每个月。

cx6445

原帖由 wwwsq 于 2008-6-25 12:04 发表



不需要特别牛。真的不用。那个存储系统，随便找几个合格的计算机系毕业生都可以做好。只是你想不想去做的问题。标准数据库难做，是难在要“面面俱到”。而我们恰恰不需要“面面俱到”。

你只要考虑：什 ...

这个我还知道，呵呵，我们公司就有自己写的分布式小文件系统在用，用来替换最高端的netapp,但是真得问题也有一些。
我觉得似乎不是几个毕业生就能设计做的。可能我第一反映想到的存储系统，和你想得并不是太一样吧。

[ 本帖最后由 cx6445 于 2008-6-25 12:15 编辑 ]