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

lose

原帖由 wuxb45 于 2008-6-26 15:35 发表
我认为……匹配用户名的复杂度很低……主要是网络延迟占时间，这个速度快应该不是google的算法问题

匹配用户名只要毫秒及的就可以接受了，毕竟和网络延迟相比不算什么。用户完全可以接受。

zerg_

Mark...

cugb_cat

原帖由 cx6445 于 2008-6-26 13:11 发表
google的三大基石

gfs,bigtable,map-reduce

相对应的开源产品

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

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

mark一下google的三大基石对应的开源产品，有时间去看看~~

kkair001

我是个大一的孩子，看帖子看了一下午，什么都没看懂...

[ 本帖最后由 kkair001 于 2008-6-26 16:43 编辑 ]

cx6445

原帖由 zszyj 于 2008-6-26 14:21 发表

发现有些人的观点无异是强奸民意, 希望他们先弄清楚几个概念:
1. 我从开始至今, 一直强调的是, 象用户名匹配之类按索引查找的简单应用, 属于管理类信息, 适合用数据库. 可有些人偏偏视而不见, 非要将"网页", ...

我个人就觉得这个应用搞个mysql就好用了，只是有些人喜欢自己写而已，大家没冲突。

carny

原帖由 lose 于 2008-6-26 14:59 发表

id怎么不会時時做交易，前面的假设不就是同时有成千上万（同一时刻10000个请求）的人在检查10亿个已有用户名里是否存在，然后创建一万个新的用户名。

那只是用id 算出hash value, 跟據hash value , 去算出在那一台node上,的那筆record, 談不上transaction
請問你一旦某一筆 id field 會時常rename , delete , update ??

carny

原帖由 lose 于 2008-6-26 14:59 发表

id怎么不会時時做交易，前面的假设不就是同时有成千上万（同一时刻10000个请求）的人在检查10亿个已有用户名里是否存在，然后创建一万个新的用户名。

那只是用id 算出hash value, 跟據hash value , 去算出在那一台node上,的那筆record, 談不上transaction
請問你一旦某一筆 id field 會時常rename , delete , update ??

可恶的

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

这个好用，超赞，web版的MSN，目前就用它。
个人觉得google的技术还是很牛的，能把Linux和MySQL优化到如此程度，很不简单。
可以说是先驱了。
继续看大家对于数据库和算法的探讨。
个人觉得，要是能提升哪怕是1％的性能，也值得，因为应用会无穷扩大。

lose

原帖由 carny 于 2008-6-26 17:21 发表




那只是用id 算出hash value, 跟據hash value , 去算出在那一台node上,的那筆record, 談不上transaction
請問你一旦某一筆 id field 會時常rename , delete , update ??

这个我也不知道google的要求是多少，这种就向奥运门票系统，一定要知道需求的大小，不同数量级，根本不同。

carny

原帖由 lose 于 2008-6-26 14:59 发表

id怎么不会時時做交易，前面的假设不就是同时有成千上万（同一时刻10000个请求）的人在检查10亿个已有用户名里是否存在，然后创建一万个新的用户名。

那只是用id 算出hash value, 跟據hash value , 去算出在那一台node上,的那筆record, 談不上transaction
請問你一旦某一筆 id field 會時常rename , delete , update ??