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

chzCPU

真正的好贴. 顶一下大家.

shan_ghost

原帖由 cx6445 于 2008-6-26 13:11 发表
其实大家都能去接触这些最前沿的东西。有工夫吵，不如去做做实验，看看源码。

对啊。

其实很多东西也算不上前沿。

google的东西，说白了其实也都还是基础知识在海量数据+网格计算领域的活用而已。



比如bloom filter好像就是1970年提出的（具体时间记不清了）；
并且这个算法，正如我在这个帖子第5页所说的，其实只是基于hash思想的深化与拓展而已，没什么大不了的。

夸张点说，要突然给我压上个类似的任务，说不定俺也能独立把它发明出来。

中国比我聪明的人无数。没有思想枷锁的话，不可能多少年出不了一个诺贝尔奖。


那么，思想枷锁在哪里？我们该如何打破它？

chzCPU

原帖由 shan_ghost 于 2008-6-26 13:25 发表


对啊。

其实很多东西也算不上前沿。

google的东西，说白了其实也都还是基础知识在海量数据+网格计算领域的活用而已。



比如bloom filter好像就是1970年提出的（具体时间记不清了）；
并且这个 ...

  关注.

lose

原帖由 shan_ghost 于 2008-6-26 13:25 发表


对啊。

其实很多东西也算不上前沿。

google的东西，说白了其实也都还是基础知识在海量数据+网格计算领域的活用而已。



比如bloom filter好像就是1970年提出的（具体时间记不清了）；
并且这个 ...

看到这里我发现大家说的都是一回事，从项目的实际出发。
我没有看到有谁在开始的时候把google的需求全部写出来，往往是争论到中间有冒出一些新的需求，在google里面的人自然觉得自己的方法最好，因为你自己最了解需求，别人的不一定就是错误的。我也不觉得提议用数据库的那个哥们就是错误的，我在他的帖子看的很清楚，根据实际的需求用成熟的技术。他不在google，对google的需求不完全清楚，给出的方案不是最优也是很正常。

cx6445

原帖由 shan_ghost 于 2008-6-26 13:25 发表


对啊。

其实很多东西也算不上前沿。

google的东西，说白了其实也都还是基础知识在海量数据+网格计算领域的活用而已。



比如bloom filter好像就是1970年提出的（具体时间记不清了）；
并且这个 ...

我一直认为理论和实现是两回事，一个理论可以比实现早个几百年出现。就象很多工业制造，道理都懂，就是工艺没别人好。

zszyj

原帖由 shan_ghost 于 2008-6-26 12:31 发表
呵呵，开个玩笑而已。

仅仅做用户名检测的话，怎么都行，但最便宜还是bloom filter。

要几十上百万的上高级服务器+oracle的话，养那些一个月几万的软件工程师干嘛？


现在我们说的是gmail，不仅仅是一 ...

发现有些人的观点无异是强奸民意, 希望他们先弄清楚几个概念:
1. 我从开始至今, 一直强调的是, 象用户名匹配之类按索引查找的简单应用, 属于管理类信息, 适合用数据库. 可有些人偏偏视而不见, 非要将"网页", "邮件"之类的属于内容管理之类的工作, 也非要挤进数据库去,  有见到过用关系数据库管理邮件的邮件服务器吗? 不知道说你无知, 还是说你野蛮.
2. 一说到数据库, 某些人一下子都引导到商业产品oracle上,似乎oralce才是数据库, 数据库就是高成本. 殊不知公开测试, 开源的MYSQL性能远高于ORACLE,而且是免费的.MYSQL不是数据库, 数据库不能免费?
3. 某些人一再举例什么bigtable, hbase, 难道这些不是数据库? 开源了,扩展了分布式支持,增加了大量字段数的支持, 换了个马甲,就跳出了RDBMS的范畴了? 即使是新的数据库模式, 不好意思, 还仍然是一种数据库. 不明白你们想表达的什么观点, 你们一再号称数据库不能用, 难道经开源改造过的数据库就不算数据库了吗? "白马非马论"?
4.文件系统和数据库, 是一种互相排斥的技术吗? GFS是文件系统,适合存放邮件内容和网页内容, bigtable/hbase是数据库,适合存放结构化数据和管理信息, 为什么google要并用,自已还没明白吗?是非此即彼的关系吗? 换你做实现, 你会将用户验证信息放文件系统,而不放数据库吗? 包括现在用户验证最通用的LDAP技术, 不也是主要建立在数据库的基础上吗?
5. 数据库也有算法,而且有很高深的算法. 说得对, 这也正是我的观点, 不知道我哪里说的话, 表示数据库就不用算法了? 恰恰是某些人认为使用数据库就是轻视算法,只有自已实现的才叫算法, 这不是冤枉别人吧?
最后,希望大家讨论,都要客观点, 就事论事, 别总带着争强好胜的心态来参与, 正确体会别人说话的本意, 才能有所启发和提高.

carny

以這種特色來看, id 不會時時做交易( insert delete update)
一定是用hash算法, 不可能用b tree建index的算法的,
有興趣者可在internet 找一下
Teradata database multi-nod動態 dynamic hash
和Oracle database 的靜態 static hash和btree index的優缺點

lose

原帖由 carny 于 2008-6-26 14:28 发表
以這種特色來看, id 不會時時做交易( insert delete update)
一定是用hash算法, 不可能用b tree建index的算法的,
有興趣者可在internet 找一下
Teradata database multi-nod動態 dynamic hash
和Oracle da ...

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

lanphaday

原帖由 zhangzhh05 于 2008-6-22 10:46 发表


那为什么别的网站做不到呢？
再说有将近上亿（保守估计）的用户名，你得去匹配吧！字符的比较有那么快吗？
那你说说如果让你来做，你会怎么去做？

做个bloom 过滤就好了。真正注册 的时候再完美比较。

wuxb45

我认为……匹配用户名的复杂度很低……主要是网络延迟占时间，这个速度快应该不是google的算法问题