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

shan_ghost

对了，人家google还有个通过邮箱实时聊天的东东。假设设计目标仅仅是千万人同时在线，又需要什么样的数据库软硬件呢？

chzCPU

原帖由 shan_ghost 于 2008-6-26 12:37 发表
对了，人家google还有个通过邮箱实时聊天的东东。假设设计目标仅仅是千万人同时在线，又需要什么样的数据库软硬件呢？

觉得有道理.

haiyan_qi

原帖由 zszyj 于 2008-6-26 11:56 发表

google使用的是LINUX+MYSQL, 虽然不用ORACLE, 但MYSQL不算是数据库吗?

我不清楚google有没有用MYSQL，你可以找出证据来证明google在用mysql。
但是google的核心是GFS确是事实。
合适的技术解决合适的问题，不要以为你用数据库就不需要算法了，Google也就会用数据库也就不需要算法了。
不要以为所有的人一样都是在做着民工一样的工作。

benjiam

原帖由 shan_ghost 于 2008-6-26 12:37 发表
对了，人家google还有个通过邮箱实时聊天的东东。假设设计目标仅仅是千万人同时在线，又需要什么样的数据库软硬件呢？

这个就是我在尝试的东西。 其实就是im.

benjiam

原帖由 flw 于 2008-6-26 11:50 发表
圣人之道是什么？就是中庸！
如果我是决策者，我会采纳 zszyj 的建议，我觉得他的想法很对，让他去实施这个项目好了。
同时我也会给他的反对者一定的时间和资金，去做前瞻性的预研。当然如果公司资金紧张那就 ...

很简单，  假设有10w台服务。  造它的做法， 前1w台 很好。只有 中国区服务  很好

3万台 好  加上亚洲区服务器 也很好

5 万台 慢  数据库不时当机， 解决不了。  

这时候我们是继续下去呢？ 还是 重新推翻？  当我们发现oracle 无法满足我们的要求了。所以
我们要求 oracel 开发个新版本。

benjiam

原帖由 haiyan_qi 于 2008-6-26 12:45 发表



我不清楚google有没有用MYSQL，你可以找出证据来证明google在用mysql。
但是google的核心是GFS确是事实。
合适的技术解决合适的问题，不要以为你用数据库就不需要算法了，Google也就会用数据库也就不需 ...

有介绍性的文章， 的确用了mysql.   但绝对不是它所说这种低劣的架构。

flw

原帖由 benjiam 于 2008-6-26 13:00 发表


很简单，  假设有10w台服务。  造它的做法， 前1w台 很好。只有 中国区服务  很好

3万台 好  加上亚洲区服务器 也很好

5 万台 慢  数据库不时当机， 解决不了。  

这时候我们是继续下去呢？ 还是  ...

继续你这个比方：
我前面提到的预研，就是在公司只有一万台设备的时候，
就为 5 万台设备做准备。
因此当5 万台 慢  数据库不时当机， 解决不了时，
自己的新技术应该已经研发出来了。

[ 本帖最后由 flw 于 2008-6-26 13:19 编辑 ]

cx6445

google的三大基石

gfs,bigtable,map-reduce

相对应的开源产品

gfs:kfs(据传google创史人的同窗所创)，hdfs(hadoop的子项目)
bigtable:hbase(hadoop的子项目)，Hypertable（从hbase项目组分离出去的，用c++实现）
map-reduce:hadoop（apache的项目，java实现，目前创史人在yahoo全力打造，已有2000个以上的节点并行计算的规模）

其实大家都能去接触这些最前沿的东西。有工夫吵，不如去做做实验，看看源码。

[ 本帖最后由 cx6445 于 2008-6-26 13:13 编辑 ]

haiyan_qi

原帖由 flw 于 2008-6-26 13:10 发表

继续你这个比方：
我前面提到的预研，就是在公司只有一万台设备的时候，
就为 5 万台设备做准备。
因此当5 万台 慢  数据库不时当机， 解决不了时，
新技术应该已经研发出来了。

为什么不直接用新技术呢？

flw

原帖由 haiyan_qi 于 2008-6-26 13:12 发表

为什么不直接用新技术呢？

因为自己的还没研发出来。别人研发出来的风险又太高。

[ 本帖最后由 flw 于 2008-6-26 13:20 编辑 ]